Kryon RPA Reviews

The primary use case is process automation. We are a financial institution, a bank. We use it to automate routine processes which don't require any cognitive participation.

One way the solution has improved the way our organization functions is that we have used RPA to align addresses between systems. We have a few central systems which hold the customer addresses. Sometimes the addresses are different in different systems. We find it very convenient to align the addresses by extracting the address from one system and using Kryon RPA to simulate the process of updating the address in the other system. It simulates the work of a clerk who used to regularly do so. We automated it and now the systems are aligned. The alternative was to develop interfaces, in the backend, between the systems, but that would have been very expensive.

RPA is part of the digital transformation. What we are doing is actually advancing the digital automation, and Kryon is a major part of it. When we automate processes, that's part of the digital transformation, making the organization more digital and more automated. The experience of our customers is very influenced by it. For example, we had a process for when a customer needed to deposit money when paying back a loan. If he didn't do it, he was late in his payments, we moved the process to the collection unit. Now, the collection unit uses RPA. The process is more efficient and the customer experience is better.

Because the processes we have automated mostly involve routine work, the solution hasn't saved business analysts' time, since they don't do routine work. But it has resulted in operational efficiencies. For the processes that we have automated, the efficiency has increased by 100 percent. We take processes that require human resources and we make them fully automatic.

We use Kryon Studio to develop new wizards and we use the features to capture elements from the screen and automate processes. We use the product thoroughly. The screen capture allows us to interface with systems which don't have an API, or where the API is very expensive, and it allows us to do on-screen integration.

The automation process is very user-friendly and the usability is very good. Developers are very satisfied with the system.

We have found some difficulties regarding the integration with legacy systems where the screen has elements in the Hebrew language. The connection to Hebrew, right-to-left systems, is more challenging.

We are discussing development of the product with Kryon.

We have been using it for 2.5 years.

We have tens processes in production. As of now, we haven't had any stability issues. It's working great.

As for increasing our usage, we develop two processes per month per developer. That is currently on schedule. We've developed tens processes but we have created interfaces to different platforms in the backend. Now, with the interfaces developed, we expect the next automation to be developed faster. The goal of two processes per month per developer is realistic.

I would rate Kryon's technical support very highly. They are very professional and the service quality is good. They try to solve the issues promptly. We are very satisfied. And that evaluation is relevant regarding their customer service. Their Customer Success provides the technical service.

We did not have a previous solution.

The initial setup was a little bit complex because Kryon needed to obey bank regulations. We have very high security requirements. They were very devoted to solving the issues and it was great.

The deployment took a total of about three weeks. 

Our implementation strategy was done in a spiral way. We started with a single process. It took us two months to install the system, get the knowledge we needed about it, and to analyze and develop the first process. This onboarding process was accompanied by Kryon Customer Success. In the beginning, we had a kickoff meeting and we decided on a day, two months down the road, on which we would have the first process in production. We worked together to make it happen. And we succeeded in achieving this goal. Then we started to analyze two or three processes in parallel, and we continue to develop and analyze the next processes.

We were accompanied by Kryon's Professional Services and we are very satisfied with them. They helped us, first, in teaching our personnel how to work with Kryon, and then they installed the system on our premises. They were very helpful in solving problems. We have a very good relationship with them.

There are other advantages from automating processes, other than saving money. We consider the cost efficiency and other advantages, such as the quality of the process being highly improved. It's very hard to estimate the cost of errors that are eliminated. But we expect that automating processes does eliminate errors.

We have a yearly subscription.

We checked several alternatives but decided to go with Kryon due to their product capabilities and the local support.

We haven't used the Process Discovery from Kryon yet. We started with processes that we analyzed and found to be suitable for automation. We find that the product, the Kryon Studio, to be very good at doing task automation. We are now scaling out and going to new processes.

The decision we made to develop the processes by ourselves with our team was a very good decision. The onboarding process along with Kryon's Customer Success - if you work together with them and consider them as partners - will work very well.

Regarding the solution's ease-of-use for business users, we use unattended automation so business users are not part of the process. For us, businesses users do not interface with the system.

In terms of finding and prioritizing processes that are ripe for automation, Kryon offered its service in analyzing processes and finding the right candidates for automation. But we were working with a consultant from Strauss Strategy. We are working with them in finding the processes.

We have a center of excellence team which contains two developers and there is a team leader who is responsible RPA. So we have three persons working with Kryon.

We use it for unattended automation and attended automation.

We are working on automating a lot of the support processes that we do within our call centers which are very repetitive. In addition, there are rates and pricing in another area where we have introduced automation. We have some automated processes running multiple times a day to evaluate rates, provide reporting, and perform rate updates, as needed, without human intervention.

We are also looking at streamlining some areas on our franchise side, where we are building properties out in our systems and updating their property information. Therefore, we are looking at those components, as well as the onboarding of new hotels.

It has benefited our organization through automated rates and pricing. We built an automated rate system that runs four times a day. Our initial analytics coming back from that rate system for a single two-day period in July performed over 25,000 individual rate changes across just under 600 hotels. 

With this volume of activity, there is no way that we could hire enough revenue managers to perform those volume of rate changes. This rate system has allowed us to be more responsive and competitive with our rates with less human involvement. It is leaving our revenue managers free to work with properties, identify special events where things might want to be increased, etc., rather than spending their time updating rates. Instead, they can now just submit a special event and what they want the rates to be, then the system will adopt these into the existing strategy that is being implemented automatically.

It has been straightforward and smooth to use this solution for the full-cycle of automation from the discovery of processes to turning on the automation and scaling it up. We have three dedicated environments: development, UAT, and production. We build things out, then test them in development. It is very easy for us to transition them out of development into user acceptance testing. Once our users are happy, it is a very easy, seamless process for us to transfer that into production, enable the triggers, and turn it on. The ease of being able to bring things into production and through the development cycle is quite straightforward.

This solution has helped our existing workforce embrace the digital transformation of our organization. We have multiple departments currently coming up to us, and saying, "Hey, when can we meet and talk about things? We have things we want to automate." We have other departments starting to to reach out and show an interest in having parts of their processes streamlined or automated. For example, one of the processes that we are working on automating would be a hotel room type of change. So, if a hotel has a bunch of rooms in their hotel, and they want to transform them into a different room type, it is a very long, slow process. It's very monotonous and repetitive. This is a really good candidate for automation. Right now, we are working with that department to automate that specific process. For them to do it by hand right now, it takes them almost a full seven days to perform, but with automation, we can do it in almost half that time. These type of requests happen regularly. Therefore, there are more of them to do than there are people. This automation will allow us to perform the requests that we have faster, but also keep up with future requests.

When we approach the departments about automation, we put a high stress that the solution is complimentary and will elevate the human workforce. This way they can do the more important things while not having to worry about filling out an Excel spreadsheet with 600 fields. Most of them, when they hear that they won't have to fill out all those fields anymore and they'll just have to worry about the more important aspects of it, they typically end up pretty happy. They seem to be pretty receptive to it. However, you'll always run into a few people who will have the concern that automation might take their jobs, but it hasn't happened so far.

With any of the processes that we have deployed, the accuracy and rate of errors coming back is much lower than what we would typically see. There have been a lot less things going through the automation that we need to adjust, fix after the fact, or touch manually.

We have relied heavily on the the data group base integration features, as well as the email and Exchange integration features. The ability to integrate with Office makes life a lot easier. One of the things that we do is interact with a lot of Excel worksheets and their information without having to load up the Excel worksheets themselves. Instead, we are able to pull the data directly from them and do the manipulations that we need, then put them back into the spreadsheet or into another worksheet without having to wait for Excel to load.

The ability to integrate with a database is a big perk from a scalability standpoint. Our automated processes for our rate programs are driven by database entry. We also use databases for our queuing systems and reporting purposes. It is proving to be the backbone of our analytics side of tracking and monitoring our automated processes and systems.

We have been using Kryon Process Discovery for about a year now. With our initial tests and monitoring just a couple people, we were able to identify 79 possible use cases within a one-month period.

For developers, Kryon is quite easy to use. I come from a scripting background. Adapting from scripting over to working in Kryon's development environment is very simple. It was an easy adjustment.

It is easy to move things through testing and into production. From a development standpoint, it is a pretty streamlined, straightforward process.

This need for improvement deals with the Office APIs in it. There have been some times when dealing with the macro interactions that we have had to build our own way of executing those macros rather than using the inbuilt tools provided by Kryon to execute them. I would like to see some improvement there.

We have also run into instances with some of the Office integration commands that are available, where we have had occasional troubles. They read the data once, hold a file open, or do something in the background. It would be nice to see the handling of this improved. This should probably be relatively minor improvements.

I would like the pool of advanced commands to increase. It does have a very solid base with a wide range of commands ranging from date manipulations through to SAP integrations. It needs to shore up those commands, harden them up a little bit, and maybe expand upon them. This would be something that would be nice.

I have been using it for five years now.

Overall, it is quite stable. I have seen some very minor occurrences where Kryon's interactions with Microsoft Office might cause the robot to hang. However, it is about one to two percent of the time where we are seeing this happen. It is such a small percentage that it's not even something that we are overly worried about. This would be where they might have some stability issues, but it could be the Microsoft Office API or how they are interacting together. It is such a rare occurrence that it is quite stable overall.

We are currently in the process of working toward upgrading our Process Discovery install. We are putting it out to a larger user base so we can start pulling in more possible use cases, which may not have been identified by somebody.

We currently have a three to five person developer team. Of that team, three of us would be critical for long-term maintenance.

It is very scalable. The solution will scale for whatever you build it to scale to. If you take the time to make sure that the design that you are implementing for processes are scalable and able to ramp up, it'll scale to do whatever volume you need, as long as you're able to throw the machine resources at it to provide the processing that it needs. In our case, we have one environment that manages rates for an entire brand of hotels, and we're looking at expanding that out to more brands.

We have three environments for the unattended side. We have a production, user acceptance testing (UAT), and development environment. 

• Production is the environment where we use it for anything which will be running and affecting real data and real environmentals. 
• UAT is strictly a testing environment. It gets used as we have processes which are ready for testing before we can deploy so we can make sure it's performing as the end users expect.
• Development gets a lot of use from the developers because that is where we are building our processes and testing them out prior to exposing the user to them.

In addition, we also have a very widespread attended side deployed across a lot of our hotels in North America. We have about 10,000 PCs with the application installed to provide training and support for the properties.

For actively developing in Kryon, there is only a handful of us. That is all we do. We work with the departments to identify the processes to automate, then determine the steps needed to automate those processes and work through that.

We have about 40 revenue managers who are working with that automated pricing system that we have. There is also a handful of other users out there who are either developing content for the attended side of things or leveraging some of the automated tasks that we have. We have built out for them to free up time to work on more important things. Right now, outside of the revenue managers, there are probably another 20 to 30 users.

Overall, the customer support is fairly good. There have been some times where we have had to go through explaining the issue a couple times because it has gone through a couple of people's hands. There have been a couple of scenarios where we have had to re-explain the issue and bring somebody new up to speed on what is going on or what the problem is. Overall, they are very responsive and very helpful.

Previously, we had tiny bits of automation, but it wasn't automation like this. It was more scripted automation. Just people running bash scripts to perform certain things for them. There was never really anything official nor a real platform in place prior.

We looked into having an automation tool because we have a lot of processes which are very time consuming, e.g., data entry-centric. These tasks take a very long time for a human to do and are very monotonous. People tend to get bored doing them very quickly. Automation was a great way of getting that fixed so we can give the human workforce more important tasks and offload these menial tasks that nobody really wants to do. We can offload these tasks to automation and keep everybody a bit happier.

The initial setup was fairly straightforward. When initially setting it up, it definitely does benefit to have some IT experience in setting up different types of servers. Overall, the process itself was quite straightforward, though.

The deployment process was pretty quick. We did it between mid-March and mid-April, deploying three environments. A couple of which only took us a day to deploy. Once you are familiar with deploying the environment, it can be done very quickly.

We kept our implementation strategy basic. We have our application server and IIS instance together on one box, then we have our database server instance on a separate box. Then, we have all of our bots linked into it. They are all VMs, so they can be snapshotted, spun up, and spun down very quickly. If we do need to bring more bots online for any particular reason, it's very quick for us to do that, as well. It is a simple implementation, but it is virtualized. That virtualization gives us a lot of scalability and flexibility with where we want to go with the platform.

We used the Process Discovery tool to help us find and prioritize processes that are ripe for automation. We have also worked fairly close with Kryon on our automated rates and pricing platform that we built out. So, we had Kryon resources working onsite with us building and deploying that platform.

We worked directly with a couple of people at Kryon to set up our initial environment. It was a partnership sort of scenario where we worked with them to determine what our needs were, then we deployed that. However, we had some people on our end doing the actual work, while Kryon had a couple of people who were making recommendations or consulting on it.

Our experience with Kryon during the deployment was good. For the deployment of the infrastructure, we had access to some very knowledgeable people about the system who knew the ins and outs of the environment's back-end, which is useful.

Kryon is saving us money on the attended side of things. Attended automation has diverted 34 percent of training calls to our tech support centers. 

On the unattended side, we used automation to onboard a brand into our management systems this past January. The automation performed those tasks over a five-day period. It would have taken a team of 20 to 30 people almost a month to do that same work. So, we've definitely seen some benefits from automation.

Kryon came into the picture before I did. In the past, I know that we informally looked at a couple other products, but we never went in-depth with them. Once we picked Kryon, we stuck with Kryon. 

We did talk to WalkMe a little bit.

Take your time. Don't rush it. Ensure that you have a few good use case scenarios to start working with, because if you don't have something to work on right out of the gate, the system will just be sitting there doing nothing as part of the evaluation. You should know a handful of processes which are good candidates that you can use as initial proofs of concept just to make sure that it will fit your needs. You want more than one, so if you do move ahead, you actually have some work to do.

Kryon is easy to use. Somebody who is not tech savvy at all might have a bit of trouble picking things up. However, if somebody is a power user of Microsoft Office or familiar with the workings of macros, this is a platform that they will pick up easily. Even if somebody is not overly tech savvy and they are at least curious or willing to to read about things, working with the commands and interface can be easy. So, if they are reading up on how to go about doing what they're doing or reading about the commands, then they will pick up the system up well.

We use it to automate a lot of data entry or do manipulation in regards to our ERP system.

We are still pretty new with the solution. We have maybe a dozen wizards right now. Some of them are different variants of similar wizards. For the most part, it is used all around our ERP system. E.g., if we have a new product that we're going to make, we take the information from marketing and engineering. That gets handed off to the bot, then the bot enters that information into our ERP. This is a pretty intensive manual entry process.

Everything that we use is on-premise.

Our company has seen crazy growth over the last 10 to 12 years. We have been up 20 percent year-over-year for that amount of time. Without some of this automation, we would not have the time to invest in developing a full solution or custom applications to handle some stuff because things are changing so quick. It's not worth the investment or there is not enough time to keep up. Constantly hiring more people isn't always an option either. It's sort of a necessity with the growth that we've seen to use this to help with some of the pain points that we have just around growth challenges. Especially at the higher levels of the organization, they see quite a bit of value in the solution.

It has really helped us with efficiency and accuracy. We literally have teams of people just sitting in front of a computers typing in data from Excel sheets all day. That is all they do. We have so many other roles and new challenges associated with our business growth that we could use those bodies. People who have been with the organization a while that we can take those people and say, "Instead of just manually keying all this stuff, go work on something that's a value-add. You know the business and you're familiar with our systems, so go do this instead." That is the biggest win, especially with our state's unemployment being pretty low and filling jobs can be a challenge when finding good people. We want to take the people that we have and leverage them for the things which really help the organization.

It is still a small footprint. In the last 30 days, we've automated 216 hours of work. That is not a lot. However, when you talk about how many people hours that is, it's probably double, if not more than that. So, it is not a huge impact, but in the couple of places that we've deployed it, it has been nice to be able to just send an email in and have it turned around to you from the bot. Within 10 to 15 minutes, the task is done instead of having to send it to a person and rely on them to do it, then get back to you, or they might be on a lunch break, etc. Some of these are critical areas where there's not a lot of time. It's definitely been a benefit to those departments.

I don't think it saves any time from the analyst or IT side. It is an investment upfront to build this stuff and to dig in and find where the opportunities are. We just installed the Kryon Process Discovery service, but we haven't really used it a whole lot yet. Therefore, I can't speak to its efficacy. Hopefully, it will help in this area. 

They make it pretty easy to use this solution for the full-cycle of automation from the discovery of processes to turning on the automation and scaling it up. We just installed Process Discovery. In theory, that should work quite well. It recommends what processes if identified are best for automation versus those that are highly complicated or have a lot of bearings. We haven't gotten the value out of that yet because it's brand new. 

The bot is typically about twice as fast as a person and more accurate, as long as the data going in is good. That is the biggest advantage.

I do like the feature if you find an opportunity that it is very simple to export the recording of that process and import it into Kryon Studio as a starting point to build that automation. It's a really good tool for our business process managers because they can take all that information to their constituents in their departments. Even if it's not robot automation, they have an opportunity to improve the process as a whole. I find that that is an added benefit to this piece of the tool. Just using it as a place to start the conversation and really look at what people are doing on a day-to-day basis. Because managers may be aware of their people's tasks, but might not know the level of manual effort that it takes to do certain tasks. We are finding this helpful. Also, building it in Studio and deploying it into production is a seamless process. It is all very simple and easy to use.

It is just great to be able to traverse software platforms. With all the variable handling and  logic that it has, It is an easy tool for a non-technical person to work with and automate across apps. Some of our business people are like, "It's like a giant macro. It works with everything." I'm like, "Yeah, at the basic core, it's a giant macro." 

We primarily use it for unattended bots, so it's pure. We don't use any attended bots. So, it's all completely automated using email triggers.

The bot will put in whatever data it receives and it has been really quite effective.

The tool helps with speed to market on anything that we are doing. It is such a quick tool to use if you're doing any sort of automation, even if it's just SQL based. 

Process Discovery is brand new. We are on 19.1 for it. I know on 19.2 that they change the architecture completely. From talking to some other companies that use this, it sounds like we are missing some pretty big features that we will need. We will be doing an upgrade here in the near term. In general, Kryon's upgrade process is basically uninstall/reinstall at this point. They don't have an easy way to upgrade the software in place, which would be an added benefit. The process is not difficult. We have just a handful of robot machines with high availability enabled, along with a couple of app servers and a couple of database servers. Still, that's 12 machines which all need to be upgraded, and that is no simple effort when you're talking about a full reinstalled software. If we fully utilized our licensing by scaling out, we'd have more than 30 machines. We would have to upgrade on the field. Then, it's a pretty big task if they release new features and things that we want to take advantage of going forward. I see an opportunity for improvement from them here.

We are using it to do some automated reporting, and right now, we can't put images into the HTML formatted body of an email. We can either attach an image or embed a link to an image, but we can't just drop in an image into the HTML. That is feedback that I have given them. It would be nice to be able to have a bot take an image and paste it in as you would in Outlook. Otherwise, we have to provide either those images on a public website. If we want them just to be attached, it just doesn't look as clean. Especially people in our sales force, who are on their mobiles a lot, are not on our network a lot. These are a challenge for them when they just want to be able to glance at the report and go on with their day. It seems like a small problem, but it's limiting for us in some of the areas where we could deploy more of this solution. We have a feature request in for this, and I'm hoping it will be included in the future.

How it delineates file names on email attachments could be better. It is a hard coded comma, and if somebody includes a comment in a file name that messes it up. It is such a ridiculous thing. Who puts commas in file names? But, you would be surprised, and it happens. This is another simple thing they could easily tweak.

Their Tier 1 support is pretty basic. You either have to jump through the same hoops every time or escalate to a different Tier through your rep. 

We purchased the solution in January.

The stability is pretty good. The only unstable part is Studio where you build this stuff. In our version, the 5.25. It has a memory leak. If you leave it open for too long, eventually it just freezes. Saving your work, closing, and opening it just once a day is all it takes. However, this is a bug that I have noticed about the stability of the actual tool. Our production console and robots have been rock solid.

We are still a fledgling operation with it. We have one guy who works part-time on the PDF and another full-time contractor working with the business to build more bots and wizards and also finding more opportunities. Then, there are two of us who are dabbling in it in addition to our regular jobs. 

It is also helpful for certain one-off updates. I am a support analyst myself for a lot of our software. People in the business will come to me with really simple problems. E.g., HR had to send out an email to every intern with some of their employment credentials and links to sites for things that they needed. However, they all had to be personalized. Each email needed to have unique information to each candidate in it. So, they built the template real quick. They handed me the email and we dumped a list of the interns from our HRS system on it. We just threw that in the bot real quick with a couple of loops using the email template with some variables and were able to send out an email to all the interns in minutes, which could have taken a whole day, if done manually. For one off things like this, it's such a simple tool and really easy to use. 

While there are other ways of doing these type of tasks, e.g., a lot of HR systems have some sort of bulk email feature built-in to send new hires information. Our HRS doesn't have that or maybe it's too clunky to use. This just makes it super quick. 

We also use a lot of similar things with one off SQL automation where we could build a complicated script and run that. However, the bot can run a loop of queries for whatever variable it might be and spit out a report. This takes literally minutes to build and run versus hours if you go different paths. This makes it a very sleek little one off thing.

Scaling is simple and very quick. The longest piece of adding any more robots is creating the VM piece and installing all the software that we need onto that virtual machine. Once infrastructure does that piece and hands it off to us, it takes minutes to configure a bot, point it at the server, name it, and get it credentials, then adding it to a production group within the console is very quick. That piece is quite easy.

For part-time use, there are about five of us who are developing it.

There are 50 to 60 people now who interact with the bot by feeding the bot information to trigger it. Also, in our finance space, we have the bot doing some automated work. It doesn't post anything, but it prepares what is called a journal in our system. It prepares a journal, then someone from our finance team will go and review it, making sure everything is accurate before posting that. They are a customer of the bot at that point. That is just a time saver, so they don't have to manually build anything. They can look it over, then they're good. 

There are a lot of people who are receiving reports from the bot. I don't know how many there are. It is probably in the hundreds of thousands.

We would love to increase our usage here in IT. We see such value with it. The biggest challenge that we have isn't even with the tool, it is internally funding the tool. The strategy around it is to automate time, then take that time and have a chunk of that time go back to funding more resources to do more automation. It's a self-feeding model and self-funding model. We're still so small that we haven't hit critical mass where we can start really adding more people to it.

We have used the technical support a few times. It is pretty standard. Their Tier 1 support asks all the same questions that you always get when you send in a help ticket. Our sales rep is extremely responsive and very helpful with escalating things if we need them to. Once we get past the Level 1 tech support team, then we get some answers.

We are in the process of talking to the technical support a little about doing the upgrade. We personally haven't gone through it yet. The upgrade process is just what I've heard from them so far on how we go about doing it. Once we go through the process and understand it in and out, that will be a big piece of feedback that we will give to our reps.

This is the first RPA solution that my company has used.

Someone in the business found the solution. We weren't in a position where we were actually looking for it. One of our business partners stumbled across it, then reached out and said, "Hey guys, this tool looks really cool. We should get a demo going." So, they set one up. Though I didn't participate at that time, one of my colleagues went and participated in that. Then, they came back with an almost like this tool sounds too good to be true.

The tool says it can traverse all apps and can take data from Outlook, Excel, and whatever ERP you have in the web, then put data in, take data out, and manipulate it, or whatever you have to do. They say it can do everything. It was like, "Can you imagine if that's accurate? What we could do with this thing? There's so much potential."

We have grown so fast and our processes have not evolved with the company. We haven't caught up there yet. So, there was a lot of manual stuff going on that we can use the tool for, and we were like, "Wow, okay. So, we definitely have to keep looking at this thing, "and that's when we got our hands on the demo. 

We might have been the first company who used the demo once they published it on their website. I remember talking to them after we purchased it, and they're like, "This demo is brand new. You're the first people that we know of to to actually use it or call us and ask questions about it." From there, we did a little proof of concept with it to make sure it would interact with our ERP, then we were off to the races.

The install of RPA was very straightforward. The Process Discovery service install went well, but configuring it properly took a couple of iterations of calls with Kryon to ensure that we had it done right.

We had QC stood up in half a day of production, not including the virtual machines. That wasn't on our team, but the actual install and configuration of Kryon was about half a day. We had two or three calls scheduled to install and configure everything else for RPA and production.

We wanted to make sure that we had a development and QC environment, then production environment. The only strategy that we had around it was to make sure that we followed the best SDLC practices that we could, as far as testing, not coding and prod. One of our guys just set up a call, then we went and did it. 

The bot took a month or so to stand up and test, then vet with the business off and on versus the six months that it would have taken to actually build a full solution. Then, if something had changed with any of our systems, that time would have been lost. That is a big savings too, just the opportunity to use this instead of dedicating a whole team of resources to a project like that.

One of my coworkers did the initial setup. We worked directly with Kryon to install it. The resource that they assigned to us was extremely helpful. Even though they are out of Israel, they were very accommodating with our schedules and always willing to help answer questions. They were very helpful and good.

We just needed one team member to deploy it and Kryon did it with us, just one on one. That was a really nice thing. I don't know about the RPA space, but a lot of times when you work with some of these bigger companies, they don't want to support their software or help install the software. They hand you off to a partner. It was really nice just going right to the guys who work to build this stuff and support it. That was a great advantage.

We are almost to a point where if I scale out what we're using it for today to the end of the year, then we have paid off the software.

We are probably saving $6000 to $8000 a month in labor costs. It's not a ton, but we're right around $60,000 to $80,000 a year with our current deployment. 

We haven't looked into it yet, but for our next opportunity, one of our business partners came across what he thinks is some significant savings in one of our departments. He is really excited to get in there and start looking at the opportunity and evaluating it for viability. If it's good, that'll be a huge win for us. They're talking about six to eight people that we can displace with the bot and and reallocating to other things.

They license per robot and we have 25 robots. You get so many robot licenses and can allocate those licenses to either attended, unintended, or Process Discovery bots. If you have 25 licenses, for example, you could have 20 automation bots and five process discovery. This allocation is flexible. There are also maintenance costs.

We also looked at Blue Prism. We just briefly looked at some demos, then we even got pricing, but we were sold from the get-go with the Kryon tool because it was so inexpensive and easy to purchase. It was very easy to learn. We were self-taught before Kryon actually came onsite and did any training for us. We had the demo for a month or two. We played around with it. The demo was very easy to learn, which was a huge benefit for us because then we didn't need to hire an expert who knew the tool already. We could just go and use it. 

Kryon is a fairly new company comparatively versus the other players in the space. There are still just the learning too.

Kryon is the most simplistic solution and the easiest to use, but the con that I've heard from other people is that the competitors are, in general, more powerful tools. However, with everything, we've thrown at it so far, we haven't found a use case where it hasn't been able to accommodate, which has been pretty impressive to me. I thought maybe we'd hit a brick wall because it just doesn't have that function or logic to do something, but it's pretty amazing what simple, basic bot programming can do with some logic.

I would really recommend the tool. I definitely see a lot of value with it. Just in the few release notes that I have read for some of the versions they've released since we installed it, it sounds like they are still adding a lot of features and functionality. We are very excited to get this upgrade under our belts and see what new things the new version brings to the table. It has been a great value-add for us personally and easy to use. We are happy with what we bought. No buyer's remorse here.

The biggest challenge that we have had isn't even with the tool. It is with the business funding it. Make sure you have a good funding model set up for funding. Our model is fine if we could actually get more funding for it. That would be the biggest thing. If we could get the business to get behind it a bit more, giving us one or two headcount to really go after stuff.

While it is a pretty simple tool to use, keep all the management centralized in IT, e.g., the operations side of the robots and keeping production access limited to a Kryon administrator who sits in the IT function. That is something that we have done really well. It just helps the stability of the bot. You don't have to worry about anybody going in there and poking at production code or breaking a process. If we did it again, that would be something we would definitely do. Once again, the challenge with that is you need to be able to fund enough people to do that.

We haven't had a lot of challenges with the tool.

I primarily use this solution to substitute processes where humans perform checks that do not need human judgment. These include onboarding, offboarding, and changing a contract. 

Kryon will allow you to automate processes fast and easy and you do not need to be a developer to automate processes. The advanced command will let you integrate with other systems quite easy.

Apart from the usual advantages (recording etc), I think the process that is presented as  'Powerpoint' slides makes it really easy to close the gap between the subject matter expert and the person configuring the robot.

It could be more reliable in spying HTML. I did expect this to be better in the 19.4 version.

I have been using Kryon RPA for almost one year.

We're looking to discover routine processes that our users do and ultimately automate those processes and deploy them to robots.

We've really been looking at just about any of processes. We've initially used it for processes that update invoices or update data on our system. We've used it for processes to send emails such as notification emails. We've used it to run scripts and to run data updates, and as a scheduling tool as well.

We've already automated about 40 hours' worth of weekly savings. It has definitely helped us to implement some of the workflows that I've shared with you and to take that work away from our partners so they can focus more on other, more valuable work.

The thing that we find the most value in is the Process Discovery component and the ability to really see what users are doing on a day-to-day basis. We're starting to make sense of the processes that they're doing and getting visibility into what they're doing. Overall, the Process Discovery is very good. The product is very new to the market so there have been some issues here and there but Kryon support has been great in working through that. It has really helped us drive understanding of what's happening. It certainly helps us understand the work the users are doing, the like things they're doing, and it helps us filter some of that work.

The product requires some more time in development. It still has some bugs and some things to work out. They're constantly releasing. They need to continue working out the general issues of using the product at scale, first and foremost.

I've talked with some of their product teams about features that I would like to see. With the Process Discovery, they're collecting a lot of data and they're spending a lot of time in the algorithms of the data. But one of the things we've talked about very recently is being able to aggregate or summarize what a user is doing in a day. That summary wouldn't necessarily be in the context of a process, but in terms of the applications they're using, the timeline of what they're doing, the number of clicks per hour. That sort of information could be very valuable.

We've been using Kryon for about for about four months or so. We are using version 19.4 of Process Discovery and 19.1 of the RPA solution.

The stability has been pretty decent. There are certainly opportunities in terms of stability, but with each subsequent release it gets more and more stable.

The product is becoming more and more scalable. On the Process Discovery side, you can collect a lot of data very quickly, so there is opportunity there. But overall, it's working pretty nicely.

We want to deploy Process Discovery across the majority of our company, which consists of about 1,200 or so people, to identify what they are doing. Over the next year, we are likely going to be deploying it on at least a couple of hundred users' machines.

Tech support is great. They've been really good and very responsive. We submit our tickets via our portal. We feel that we get really good support from them.

Our interactions with their customer service are great. Really great. We've had a variety of people off and on, not a specific person. We've probably worked with half-a-dozen people, and all of them have been able to help us pretty successfully. We do have an account rep who manages our account from a higher level, and she has been consistent with us and has been really great.

We did not have a previous solution. We came across Kryon from an RPA consultant who wrote a book on RPA. He used it a while back and recommended it to us.

The initial setup was pretty complex. The install is certainly not for the faint of heart. There are a lot of options and a lot of ways you can install. Given that we were installing in the cloud too, it took some time and it took some troubleshooting and work, but we got there.

It took somewhere in the neighborhood of a month for us to get the AWS environment up and running and then figure out all the nuances and dependencies of the install.

Our implementation strategy was to work side by side with Kryon and our network teams and get it installed. They gave us some initial pre-reqs and things to install and things to look at. We were one of the first to get everything operating in the AWS environment, so there were some specific things to us that we had to figure out on our own.

For the deployment, we had the equivalent of one dedicated person for a month. And we have the equivalent of two people maintaining it. They are RPA developers who work on setting up RPA jobs and configuring Process Discovery, etc. We have five users in total.

We've done it all internally thus far.

We have absolutely seen return on investment. We felt that we had to get to between 40 and 80 hours of weekly savings to get our ROI and we're already almost there, and that's good news overall. So far it's saving us about $80,000 annually. We expect that number to grow.

In terms of business analyst hours, it hasn't saved time there yet, but it will over the long haul for sure. It has definitely increased operational efficiency and has reduced human error by a pretty great degree, for the things we've automated. It does what it needs to do pretty routinely and pretty flawlessly.

The cost is fairly similar to its competitors' costs. It might have been a little bit more reasonable than the others, and that cost was with Process Discovery in addition.

There were no other licensing costs, but there are our hosting costs and our own AWS cost.

We evaluated Automation Anywhere, Blue Prism, and UiPath a little bit.

The biggest difference was that Kryon had Process Discovery and the ability to discover your processes across your base, and the others did not. That was a big differentiating factor for us. Automation Anywhere was starting to come out with its cloud deployment so users won't have to deploy everything internally. That was something that sticks. But in terms of the rest of the capabilities, they were relatively at parity.

Spend time focused on standing up your center of excellence around the solution. Kryon gave us some great advice on that in the sales process regarding defining what we're trying to do with it. Get key sponsors and then get a key team that works through the implementation, together.

What we're learning from using the solution and what we're really still trying to figure out is what is a good candidate for an RPA process, versus the other ways we could automate, whether it's process elimination or deploying some of our core engineering teams to write different tools. We're still trying to figure out what the framework is for picking the best processes.

The processes that lend themselves to RPA are processes that are highly repetitive, high volume, low-judgment types of processes, where you can write down the process in a Word document, write down the logic, and then turn that into an RPA solution.

We haven't been able to make that leap yet, in terms of Kryon's full cycle of automation from the discovery of our processes to turning on the automation and scaling it up, but we see the potential there. We haven't quite gotten to that point yet, given how early on we are in our journey.

When it comes to using the solution, for both business users and developers, you do have to have some technical background to use it. It's unlikely that you would deploy it to somebody who doesn't have any background in it. But people who are somewhat technical have been able to use it pretty successfully.

I would rate Kryon at eight out of ten. It has a lot of potential and we see that potential. It needs a few more iterations for me to bump that score up higher. It has been a good experience so far and we're looking forward to the future.

We only use unattended bots right now. We build processes to help business departments in our company to improve processes through automation of pretty easily "bot-able" ideas.

We have a bot that creates a proposal using a request-for-proposal template that people fill out. We then create the proposal, based on that information, on our internal site. Another one is where we mail out payroll files that come in by reading a portion of the file to get payroll dates and the like. Those are two of our really big ones. The payroll bot saved 15,000 hours last year. For the other one, while I don't have specific metrics on total time saved, it went from a 30-minute, manual prep process to an eight-minute bot process.

It has helped us to find and prioritize processes that are ripe for automation, when we go searching for ideas. We just haven't been able to reach every department in our company yet because we're a big company and there's only so much time.

Our business users love it. Those 15,000 hours saved are a fantastic result and we're at a 99 percent success rate. Our bots very rarely fail, and if they do, most of the time it's because something is wrong with one of the websites that we are using and an unexpected error pops up. But they are loving it.

Finally, it has helped to reduce employee errors.

We do have bots where we use .NET plugins to make some of them faster, but other than those, I have built most of the bots that we have. Even though I'm in IT, I'm a business analyst. As a business user, it's so easy to use. With the recording of the processes, we didn't need to hire a specific developer. We do have one now because there was only one of me, but we are able to build most of our processes without having to develop the actual development skillset. It's nice to have that skillset here, because we can scale by using .NET, but the simplicity is the biggest win.

At first, we had problems with the object detection but in this latest release it has been better, and I think it keeps getting better. They also came and trained us a little bit so that helped.

There are some known defects that are on our list for the next release, but that happens. It's technology. They're aware of them and they're working on them.

The stability has been great. We've had one incident in a year-and-a-half, where we were down for about four or five hours. It affected everybody, not just our company. As far as I know there was a hotfix that they had to put out. But in all that time there has only been that one day.

The scalability has been good because of the .NET aspect. If it wasn't for that, they wouldn't scale.

For example, we had one bot that we built which needed to run every day to download documents off a website. It had to go download a lot, sometimes up to 500 documents a day. It never finished because the website wasn't stable enough to run for hours and hours. The bot would end up failing because it took hours. Now, we download one document now from the website and use .NET to split out the PDF files for each separate document that we need. Instead of downloading one at a time on the website, we use .NET to download one, and separate all 300 of them. If we didn't have .NET they wouldn't be able to scale.

With that capability I don't see any limitation to that scalability. .NET has been a lifesaver.

We had another one that we had to change recently because it took the bot six to eight minutes to do the whole process the way the business users were doing it. We needed to do 900 in a day. Even running it on two different servers, it wasn't going to get everything done in the time that we needed it done. Instead of throwing it away saying, "Sorry, we can't use it," we changed the process for the business users and said, "Hey, can we do it this way?" and used .NET. There is a little more front-end work that the users have to do if there are errors, but not very often. Most of the time it goes through. With .NET, it does the process in 30 seconds.

We use the. NET plugin everywhere that we can because it makes things faster.

Their tech support is pretty good. The people I've worked with have been good. The time zone issue sometimes was difficult at first, but they've fixed that with a USA support team now. It's gotten much better.

In terms of customer service, everyone that I've worked with is great. Ryan is our guy and he's very good. Whenever we've had to escalate things — we've had some issues with bugs and things that we weren't expecting — he has done all of the escalations for us. 

They came out here and gave us a four-day-long training but it just wasn't going to work for us to go to them in September or October when they were going to have more training. So instead of us going, they offered to come to our office and have a mini-training session with just us. That was awesome. That was part of their standard service.

We did not have a prior solution.

I was not included in our initial setup. That was done before I was brought onto the team. But I am familiar with upgrades. 

The first upgrade that we did was not fun at all. It took seven or eight hours. The second time, when we upgraded to the 19.1 version, it was an hour-and-a-half, both because we got better and because they provided better documentation. We also got a QA environment, which we didn't have before. When we installed our QA environment, I don't think it even took half a day.

Part of the difficulty with the upgrades was that we didn't know any steps that we should have taken, because their documentation wasn't step-by-step. So we were on the phone with them, walking through the upgrade the first time. We missed steps because the documentation wasn't there. But the second time, the documentation was great. We knew exactly what to do. Our app engineer had all the setup stuff done before we had our meeting with Kryon, and we just walked through it. It was awesome.

There were two of us, from our organization, involved in the upgrades. Kryon had people on the phone but they weren't doing anything. They were just watching us.

In terms of maintaining the solution, there's one person who handles all the bot servers and there's one admin on Kryon but he's super-part-time. It takes maybe five percent of his time. I haven't had to talk to him for weeks. And there are two of us on the team who handle the support and the bot building. There are six departments that we have built bots for, and I don't know how many people are in those departments, but they don't handle anything with them. They don't have access to Kryon. We handle everything.

The OCR reader, to help read non-digital PDFs, has a separate charge. We don't have that plugin. The only other cost that I know was separate, at the time, is the Process Discovery. I don't know if that's included in a bundle now.

We evaluated Automation Anywhere and Blue Prism. I wasn't involved in all of that process, but the biggest thing in our decision to go with Kryon was that IT didn't need to own it. Although our IT has it right now, a process improvement team could have actual business users building processes. It can't just be them, because we have to have oversight with the .NET stuff. But with the easiness of it, we just had to go with Kryon.

The biggest lesson we've learned through our time using it is the .NET component for scaling. One of our biggest lessons is to use that wherever possible because it makes things so much quicker. Also, if you look at some of our old bots that we built versus some of the bots we build today, it's crazy that we even knew what we were doing. The process flows and understanding what can and can't be bot-able, have gotten way better.

My advice would be to have a team. Make sure there's a developer so you can do plug-in things and make sure that you understand the setup and the admin tool. That was a huge lesson learned for us, going back. The way we did the setup was incorrect so we had to re-record all of our bots the first time, and that was a disaster. We didn't have it set up right because nobody told us how to do it. We didn't have that support at the front-end, for the setup pieces, for everything we were doing. 

And always have a QA environment first. We did not have a QA environment. When we first went live we didn't know it was an option, and I don't know if it was an option at the time. I imagine it's standard now. We have a QA environment now, but we don't have any data set up or any automation to set data up so we can't test bots in QA. We have to test them in production because we didn't go through that work. Testing was a mess. That's no longer true for our current bots, the ones we're building today, but it was a mess for all of our old production bots, anytime changes were needed. So always have a QA environment or a Dev environment.

It's been hard to get it off the ground. We have a really small team, so there are not very many examples. We have quite a few bots that have saved a lot of time, but I know that we could have way more. We just need a team, and I think we're going to get one, although not right this second. Kryon hasn't helped our workforce embrace the digital transformation of our organization because we only have that small team right now. People are seeing things and say, "Yeah, that's awesome," but we can only move so fast because we're so small. So people are not super-excited about it yet. They still need more exposure to it. We have about 15 bots in production right now, but it's pretty much focused on one section of our organization, and we're a huge organization. We have plans to increase our usage of the solution. There's a whole new process improvement team coming. Once we get out there more, I'm sure it will expand.

The Kryon Process Discovery is not included in our license right now. We just haven't done it yet. We've looked into it but we haven't done it yet because it's pretty complex. With the version that we saw originally — it might be different now — when it first came out, you needed special computers for it which we would have had to buy and deploy for the users who use the processes. It wasn't something that we were going to do at the time. It's not something that we have thrown off the table, but at the moment we're not using it.

Just learning what bots do, what RPA does, what I can and can't do, has been part of it. I can go to any business unit, now that I've built bots, and say, "Yeah, I can do that," or "That's not a good idea." I know exactly what I can and can't do in Kryon. I don't know if any other tool can do things better because I've never seen any other tool, but I know what I can and can't do in Kryon.

The original training that we got was a week long and we were trying to build bots in that same timeframe. So we didn't get a whole lot at that time. When we took their training classes online and had them come to us and train us in more in-depth, it helped a lot.

Everything that we do use, that we know how to use, works nicely. I love it but I'm not going to give it a ten out of ten because there are issues. I would go with an eight. They've gotten so much better at all their stuff. The tech support was part of our issues for a long time, but it has gotten a lot better. They're getting all the training classes online and they keep those pretty updated. They have a community now. They're learning and growing and they always ask us for feedback on every aspect. They put that in their backlog for future prioritization. They're listening to us.

Our primary use case is two back-office processes from a specific area, an area which was very complicated. In the credit card world, there is a process called a chargeback, when the customer says he didn't do a specific transaction, or it's not the right amount. This process has a very long, complicated and regulated process behind the scenes, after the conversation with the customer. We used a robot to automate a lot of the process, to make it shorter, easier, and to save a lot of agents working on the process.

Every week or two weeks we are bringing on a new process with the robot. We are still in the middle of the automation move; we have a very big roadmap for what comes next. We are still on this trail.

The process I noted above is a main business area with a lot of very specific processes inside - we have now more than 15 specific processes in this business area. All of them, as of now, have saved us almost six FTEs. That's a lot of money. The savings are great and they will increase every month.

In the last month, we achieved 11,000 activities done by robot. Before Kryon, we did 500 each month. When we started with automation ten months ago we did a few hundred. Each month we have added more and more processes and more and more activities. It's quite dramatic, because we took a very complex business area, and every activity in it which can be done automatically is being replaced by the robot instead of people working on them.

In terms of Kryon helping us embrace digital transformation, we are very advanced in this area. More than 70 percent of our interactions with customers are digital. But Kryon helped us with some of the processes which are more complicated, where we had people doing things in the back-office after the digital process. Now we can do more of them automatically. It's another step in the same direction for us.

What we are lacking is OCR, the ability to read text. We would like it to have the ability to take a page which is free text and analyze it, and then for the robot to know what to do next. This ability does not exist in Kryon products, so our company is now trying another tool which has this specific feature - an IBM tool which combines RPA and OCR together.

Also, when the robot stops working for any reason - it doesn't matter if it's something in our systems or our infrastructure - it does not know to go back to the same point it was at when it stopped. We have to start from the beginning or to delete the report. It cannot continue from the same point. We would like the robot to know how to continue.

It's quite stable. Most of the difficulties are coming from the changes on our side.

The scalability has been good enough for our needs.

Prior to Kryon, we didn't work with another solution. But we are now starting to work with another solution because of OCR.

On the technical side, the setup was done mostly by HMS. The issues we dealt with were mostly to do with the connection to our organization's system. The authorization issue was difficult for the system and many other aspects, but I know part of it was from our side. We also had some information-security issues. I don't think it was too complicated, but it took us about a month-and-a-half, to do the first at set up, and then it was much easier.

We learned a lot. We learned what we need to prepare for each process so the process will be the most effective and quick. We learned about the abilities of the tool and that helped us in thinking about the next processes and how to do things more efficiently.

We are also using BI to help us with more complex business logic. Instead of doing it in the robot, we are doing it in BI and giving the robot more direct reports to work on. It makes our process much smarter and efficient.

In terms of deployment and maintenance, we have one full-time employee working on it, and one of our business persons, a project manager, is working on it half-time. He's involved in building the business process, deciding what will be the next step, and helping close all the details on our side.

The maintenance is not high. It's just that each time the system is changing, we need to teach the robot the process from the beginning. This is the only maintenance we have. The other work is really to in developing the next process each time.

We have a supplier doing the implementations for us, HMS. They are more involved in the technical details and issues. But next month, we are planning to do Kryon's course. We are bringing it here, and then eight people, both business and tech people from our organization, will learn the tool and then we will be able to use it by ourselves.

Our experience with HMS has been very good. We like working with them. We are continuing with them but from a budget point of view we would also want to learn to be more independent. But we'll definitely continue working with them.

Now that the process is cheaper for us, we have been able to change our business rules a little bit and save more money by automating. To give a simple example, if it was worthwhile for us to do a specific activity only if it was more than 50 shekels, now, when the robot is doing it and it's cheaper for us, we're doing it from the first shekel. We are saving more money by changing the business rules because the process is costing us less money.

It has also helped to reduce employee errors. This is also very important. And it has helped us in terms of monitoring because we need to do less monitoring of the employees. That's another area of savings, another improvement. In the beginning, we did need to monitor the automated process, but after seeing it and becoming comfortable with it, we were able to reduce our monitoring of employees.

The first robot was very expensive.

For us, there are the additional implementation costs that we paying to HMS.

We have a lot of people coming to us to learn from our process, so we've been providing advice already. First of all, it's important to do a very smart business analysis, from the business side, and not automate exactly the way it was done before. Really think about ways you can improve and make the business logic, the business rules behind the scenes, more effective. This is very important.

It's also important to look at becoming independent with the solution from the beginning. We have only started to plan for that now.

The authorization issues within our company also took a lot of time, so I would suggest getting those dealt with in advance.

Part of the difficulty in embracing the tool is on our side, due to bureaucratic issues that we have in our organization. Every change we make which results in a new version of the system the robot is working on means we need to teach the robot from the beginning to do the process.

For example, when we would have a new version of the system, we would ask our people, "Has anything changed?" They would say, "No. Nothing is new." Only after would we find out that something moved from the right to the left. Just one button. For the employees, it didn't matter. For the robot, of course, it does. And then we needed to teach the robot to do it again. So we have learned to prepare ourselves better before a new version is released. We receive all the screens. We teach the robot to do everything again. We're checking ourselves. We test more. These are things we learned along the way, "on-the-job learning." We wasted a lot of time on this because we did not prepare for it properly.

In terms of the prioritization process, we are working with a business analyst to decide exactly what the next process should be, what has the biggest number of activities per month and that the business case is important. We also look, from an implementation point of view, at whether we can do it. Is it accessible for us and not something very complicated which will not be possible? We take all of this into account and we decide which process to put in next. We already did the main business area and now we're continuing to another business area and doing the same process. One of the things on our roadmap is to optimize part of our monitoring processes.

From a business-analyst point of view, we are using a lot of analytics to make it very smart and efficient. So it's not saving us money in business analytics, it's the opposite. But it's worthwhile for us. The discovery process in our methodology is very important because each case is a little bit different, so we need to find the right rules, the logic.

The first process was the most difficult. We needed to learn how to work with it. But by using it more and more, we have achieved a very easy and quick process. The delivery time, now, is very good for us. We are adding a new process every two weeks. Now it's good, but the first time was more difficult.

We're automating a lot of shared services tasks within our homegrown system: payroll, billing, and things like that.

As a company that places temporary employees, we have talent globally. In the UK there are GDPR requirements. Before Kryon, when one of our field employees reached out to us saying that we needed to remove their records, that was all done manually. Now, that’s something done by the robot, giving people time back and reducing possible entry mistakes. It’s the same thing with fee entries within our system. That is something that might take somebody ten hours, whereas a robot will be able to take that off somebody’s hands and ideally reduce the time to complete.

In terms of embracing the digital transformation, there is the question of whether people are going to be accepting of tasks being taken away from them and what they're going to do with that time. But a lot of people have really embraced it, especially people who were taking ten hours to put fees into our system and who will be able to use that time for more productive and less mindless tasks.

The advanced Excel functionalities are really convenient because we work a lot with spreadsheets. It’s also easy to use the HTML selectors on most major sites. It’s just a click and it picks it up. There’s not a lot of no hard-coding with it.

While I have some technical background, everything is self-taught. I'm not necessarily a developer myself, but picking up the tool, with the training they provided, has been pretty easy. I’m currently the only person using the tool in our company.

We use Google Drive a lot. If somebody sends us a spreadsheet or a document, it's going to be in Google’s format. It's not going to be in Microsoft Office format. But currently, there's no integration with Google’s documents. That would be a huge plus to have.

The same goes for, using Chrome natively. There's an extension but it doesn't necessarily always work. We have to close Chrome and reopen it to get it to pick things up sometimes, depending on the page and the IFrames and things like that.

I’m not sure yet what I think about the stability of Kryon because we haven't been able to get things constantly running and working. We initially had the server issue. And then, there have been issues with Chrome crashing and the extension.

Right now our usage of Kryon is limited to our shared services team. We're taking care of those processes first. But we have plans to automate as many processes as we can get on our plate and get through.

We have room to grow. We just have to figure out where we need to go from where we're at now. Right now it's a waiting game to get things fixed and running.

Customer service gets a rating of 100 percent. They’re fantastic. They're always really quick to respond. If we have a problem or if we put in a ticket that is more high-priority, our rep will jump on it and get things escalated. They’re happy to work through issues and take as much time as needed to resolve everything.

The Kryon team has definitely helped prioritize processes that are ripe for automation. It's an ongoing process, but they give us a good understanding of what to expect and how to figure those processes out; what can and can't be automated. It was mostly through the training. Going through that with them gave us a better understanding of what sorts of processes make sense.

We didn’t have a previous solution. We went with Kryon because of

• the ease of use
• the user interface seemed a lot better, more usable
• some advanced features that others didn't have
• the price - can't beat the price.

We had somebody within our department doing the initial setup, although I was on the calls. It was a little bit complex, because there were some issues we ran into with Server 2016. When we tried to run an unattended bot on there it wasn't working so we had to switch operating systems. We've had to go back and forth to get things truly set up and ready to go. We're still working on the deployment, but that's not necessarily because of Kryon issues. It took some time to figure out the issue with the server, going back and forth with screen-sharing, etc.

And it seems that the size of the virtual machine that they provided with us might not be enough. We're trying to figure that out. Chrome keeps crashing on us. Once that is resolved, we have three or four processes that are pretty much ready to go. I just have to get through the actual testing of the running the unattended bots on the virtual machines.

In terms of an implementation strategy, we are working with our shared services teams to identify the processes. We have a daily “stand-up” and a weekly planning session to figure out and prioritize our processes. Then it's just a matter of building and testing and getting them out.

I expect that Kryon will save us money. It's too early to tell, but I would say that once it starts running there are going to be cost savings.

There are different pricing levels for every bot or unattended bot. You can buy however many you want. You'll need an additional virtual machine for it to work on. You can get multiple attended bots if you have users who have Windows machines. You can run those locally on their machines.

Automation Anywhere was one of the solutions we looked at. There were others but it’s been a while since we went through all of them.

Make sure that you have your processes in a good place and that you have them written out. Make sure that you have your stakeholders onboard. And make sure that your bot works on the right server.

We don't use the process-discovery functionality of the tool. We're identifying our own processes by polling various stakeholders to see which processes make sense to automate. But it seems like it's pretty easy. We've hit a couple of snags with our virtual machines and the OS they are running and with the Chrome Extension. We're doing everything with unattended bots since we're primarily a Mac-based company. We're not able to run them on people's local machines other than the machine I use to create the Wizards.

In terms of operational efficiency, it might be a little too early to tell because we're stuck right now. But in the big picture, not only are we identifying processes, but we're also figuring out how to improve the processes, whether somebody is currently still manually doing them or a bot is doing the improved process.

As a company in the insurance industry, we use it for various functions within finance, such as identifying duplicate invoices, reporting, some operations functions - moving information from one system to another - as well as claims-processing.

Kryon has saved us a bunch of money and time. Specifically, it sends reminders out for claims that have not been actioned after a set period of time; for example, dormant claims, which haven't been updated or touched in five years. We actually created a job to send out reminders to the brokers to try to get updates. Since then, we've been able to close numerous claims and therefore reduce our reserves by literally millions of dollars.

It has provided overall money savings and overall time savings. We've got dashboards that show our overall stats from all our jobs. So we can say robotics has saved X amount to date, Y hours per department. Some of the jobs measure finances. There are literally hundreds of hours and millions of dollars in savings.

The solution has also increased operational efficiency. The percentage varies per department, but there are some departments that are saving two hours a day of people's time, so that's quite significant. If you think about an eight-hour day, that's 25 percent for a department which is already stretched thin. Time is extremely valuable when resources are slim.

We have also seen a reduction in employee errors. One of our jobs for finance looks for potential duplicate invoices. There were instances in the past where duplicate invoices were sent out, bills were paid twice, etc. It has dramatically reduced that. I don't think we've had one since we implemented the job. The automation searches for anything that looks similar in specific fields, using search criteria, and then produces an exception report. Instead of having someone go through 10,000 lines in a spreadsheet, they then have about 50 lines to compare. Obviously, it's much easier to identify duplicates in 50 lines as opposed to 10,000.

Finally, Kryon has helped our existing workforce embrace the digital transformation of our company. There is, obviously, resistance to change no matter where you go. Certain people will respond differently. But overall, the response has been really supportive and positive, especially from management. They're very happy with the way things are developing, the way time has been freed up. Most of the developers, and most of the people who use the automation, are also happy. There are only one or two people who feel a little threatened by it still. They don't really voice it. It's just that you can sense the resistance. I think it's a fear of their jobs going away. In our case, there's enough work that people just need to be repurposed and do other work. There's more than enough work for everybody. It was never one of our objectives to eliminate full-time employees.

The recording capability is valuable because of the amount of data it captures automatically. It's quite good. It means less development, and fewer configuration settings to fill in after you're done.

It's quite easy to use, end-to-end, minus the Process Discovery piece. The ease of use is probably the best part about it. For developers, the program is very user-friendly.

Process Discovery currently is not working for us. It's not giving correct information, correct stats. It's an issue that is currently open with Kryon as a ticket that they are investigating. In our instance, it did not function as advertised. As a result, business analyst hours haven't factored in because Process Discovery is generally the piece that's supposed to save business analyst time. As of right now, we've saved no time in that area.

Also, troubleshooting and debugging could be improved. It's missing a proper debugger. It's very difficult, based on the log files and the fact that it doesn't have a proper debugger, to troubleshoot issues. It will sometimes end with no indication as to why it ended and it becomes a bit of trial and error. Obviously, that is not a great use of time. If there were better debugging tools and logging, we'd be able to find the issues more quickly and fix them more quickly.

Right now we're having issues, so you've caught me at a bad time. Once you get it in and working, it's quite stable. Part of the problem goes back to the development. Our biggest frustration at the moment is the time to develop, because we are doing a lot of trial and error. It goes back to that debugging and lack of logs. It takes quite a while at this time, longer than we would like, to move a job or prepare it for production. Once it's done and in production, it's very stable. It's the development part that is the problem. Once in production, it is really stable.

We are a small company, so we haven't really scaled that much. We have about five departments using it and we have under 25 jobs. We're not that large at all.

In terms of creating new automations, implementing new robots, we haven't seen any issues at all. It's very simple to scale. Creating a new job, adding new robots, are both very easy to do.

All our bots are unattended, so very few people actually "use" Kryon in our company. We have approximately seven or eight developers in total during different periods of the year. Some are more active than others. For example, in finance, when it comes to quarter-end, they don't really develop. They leave the automation alone for a couple months while they take care of their busy time of the year. It comes in waves.

We have five robots in production currently. As of now, we have no plans for increasing. We've got lots of time to add stuff.

The support is really good. 

Their first-level support needs a bit of work. If we put in tickets, very often we get a bunch of questions from level-one but that information was already in the ticket. We get repeat questions. 

The only complaint I have, if you want to call it that, is that I would like to be able to pick up the phone and call someone. If we enter a ticket, by the time someone replies to it, we have continued working on our issue. The job has often changed, the situation's changed, or the issue may be resolved by the time someone replies a day or two later. Being able to pick up that phone and talk to someone immediately would be a tremendous benefit.

They don't have an extra level of support that you can purchase. There is just our client manager. If we have issues that support is not addressing quickly enough, we just escalate and then they take care of it from their side. They get someone to get in touch with us. But it would be nice to be able to pick up the phone and not even have to enter a ticket. Half of our questions could be answered immediately if we talked to someone directly, as opposed to going back and forth via email. Once it's an email, it's stretching out from a five-minute phone call to three days later before we get the end answer. I'll ask a question; they'll ask a question in reply. It goes back and forth in an email exchange.

There's no live support available unless we pick up the phone and call someone directly, but for that there's no support desk. I'd be calling our client representative who's really a sales guy. He's not a tech support guy. He would follow up with someone in tech support to get in touch with us.

With this client, there was no other solution in use. I use some, myself, as a consultant with other clients. I've been here for the last almost two years. Prior to that, I used Cherwell which is more like an IT service management, workflow-type tool.

The setup was very straightforward. Kryon dialed in remotely and did most of the work, along with our infrastructure guys. There were no issues there. It was really smooth.

They did it in sync with our guys. We had someone with the proper access and rights, so if they needed to do something on the server, for example, we had an engineer with admin rights on the call and able to assist them remotely. They worked closely with our lead engineer for IT to get it in and there were no issues at all.

The installation itself was just hours, literally. It was really quick.

It's the same with upgrades. Upgrades are very smooth and they don't take very much time at all. Kryon staff do the updates as well.

As far as the installation of application goes, there was no strategy. We just followed the steps in order.

Where implementation of robotics as a program is concerned, the strategy was to get some low-hanging fruit, some easy jobs with high ROI, and try and to show success. With that success, we rolled it into buy-in from the rest of the teams. Something else we did as a strategy was that we put a developer in each one of the departments, so it wasn't someone from IT doing the development, it was actually business-users. That way, people's peers would be designing, implementing, and developing whatever is being used in their departments. We got the subject-matter experts to actually design their own jobs. They chose what to automate, when to automate it, and then they would automate it themselves. It wasn't "Big Brother" pushing things on people. What they wanted to automate, and when they wanted to automate it was determined within the department. That created a better buy-in for implementing change and for change-acceptance in departments.

People always have their backs up against the wall if it's someone forcing something on them: "Oh, now you have to use this application." The response is often, "Well, I don't want to."

This way, it was them and their peers deciding what they were going to automate. It was much easier to get their buy-in. They determined as a group what they wanted to automate. It created a better culture for change-acceptance.

Automation Anywhere was the other one they were considering. I think they looked at a couple of others, but that was before I was here. I saw the paperwork comparing the final two and they were Kryon and Automation Anywhere.

You do need someone with some development knowledge. Not necessarily everybody involved has to know development, but as a resource, it would definitely be important to have. A straight business-user who isn't strong in IT or development wouldn't be able to do half the things that we've done. Having someone with a development background, at the very least as a support person, internally, is tremendously valuable.

As for saving time when launching new automations, we don't have anything to compare with because we didn't have an automation solution beforehand. It's new to the company. I would say our developers have gotten more proficient, so we've become quicker at development. As far as the launching now, though, it all takes about the same amount of time.

Regarding business users, with no technical background, it definitely can be used. We have users of all levels of technical skill. Business users can create some basic jobs, but there are some limitations to the product. More technical users can get around the limitations using scripting with JavaScript and the like. If people are familiar with that, it definitely makes the development phase much easier. It's totally possible for business users to use it. We've had users who have done basic jobs, but when it gets to more advanced things or quicker ways of doing things, a little bit of development knowledge goes a long way.

For deployment, maintenance, or upgrades of Kryon, there are two of us. I'm involved in coordinating and our lead IT guy works with whomever they assigned from Kryon. I'm not even necessary for those tasks. Really, just one person is required. I do the change request. I take care of the bureaucracy and the red-tape approvals and the like. Once all that's done, we hand it off to the technical team and there's a single person that does it all. He is the IT lead. As needed, he'll pull in DBAs or whoever, if the situation calls for it. He coordinates with his team.

Our company buys products from vendors and sells services to end-users. Most of the RPA processes done in Kryon are related to order raising, as well as retrieving reports. We have automated processes involve SAP, Pegasus, ITSM tool, Words, and Excel.

It takes a lot of work and time to complete the business processes manually. When the users utilize the Kryon solution, it cuts off more than 50 percent of the processing time as the logic has been pre-built. There are less orders being delayed. Adopting Kryon solution has significantly improved the turnaround time.

The image recognition in recording actions is very helpful. It runs stably as long as the graphics on the applications are not changed.

The environment of storing the variables could be defined as local, which will only be accessible within the wizard itself and cannot be read by the embedding wizard.

It will be good if Kryon has a function to find/replace the keywords and collapse/expand the groups.

We did encounter some issues regarding to trigger often but our support team is able to resolved it later. Other than that, it is quite stable.

It is very scalable. All we need to do is to set up the robot accounts and assign the access to it. Once it is done, we have to configure the trigger for the robot. Scaling up and down can be done in just a few steps.

The customer support is outstanding. They are very responsive and will accommodate with our schedules.

No, we started with Kryon.

Setup for Studio and Robot is pretty straightforward. We have to install the Studio and Robot on the machines, create accounts for the users and assign access rights. Then login Studio to develop wizards and Robot to run the wizards.

The initial setup of server was done together with vendor. Subsequently, vendor team came down to help us with the upgrade. They are very helpful and knowledgeable.

I am not too sure how much cost was saved. But there are a few people in the department were redeployed when one of our processes is up and running fine.

I am not involved in any of those.

We are using UiPath in conjunction with Kryon. I feel that Kryon has a better image recognition than UiPath.

I have tried a few solutions and Kryon is the most user-friendly.

The solution is easy to use. Although I felt the solution is a little restricted sometimes as I could not call any external libraries, I am able to use the advance commands, which are the built-in functions in Kryon, to program the RPA solution by changing my initial idea. It makes me think out of the box and test how good my logical thinking is.

We manage customer accounts: their orders, modifications, account cancellations, and back office stuff. For example, our clients are network marketing teams. Therefore, they will have accounts for multi-level marketing (MLM). They want their orders and accounts modified. For some of them, we want to change their subscriptions or cancel their accounts. These are all submitted as requests through online forms. Then, we will take them and do the modifications. We do this process automatically through Kryon.

All our bots are actually licensed for unintended, but we are not able to use them. So, we have currently 15 bots and all of them are attended only.

It has been helpful in reducing the manpower and error rate since we are able to run tasks 24/7 without interruptions. As humans definitely take breaks and there may be absenteeism that is unexpected, the solution provides continuous work. Humans tend to make errors once in a while, but the solution has almost zero percent errors.

We are able to cope with our clients's demands. No matter how much volume they throw at us, we are able to get it done quickly. That is where we see the biggest returns.

If a client gives us a new task, and it is a recurring volume, procedure, or SOP, then we are able to automate it within approximately a week. Then, they will be up and running with that automation. 

If it's a very simple task, we can automate it within about a week. If it's complex, then it will maybe be a couple of weeks to three weeks at most. We mostly differentiate simple and complex tasks by the number of steps involved. Sometimes, we need to cross check multiple accounts for a single request. We need to ensure all the information comes back correctly and that the logical calculations are done correctly. The more number of steps, the more complicated task that we will consider it to be.

We do code level modifications, which are already prewritten, and everything is with us. We don't use any of the advanced features of Kryon.

The simplicity of it: Kryon was very easy to learn and implement. The learning curve was very small. It didn't take a lot of time to set up or go live.

It is easy for business users to utilize. Mostly, it is a visual based tool. You don't need any expert coding knowledge. Even if you don't know anything about coding, a couple of weeks training should do the trick, as long as you are able to identify the logic behind whatever task you're going to automate.

While it does help reduce manpower, we still do require manpower because there are some processes and steps that we cannot do with automation. It may be too sensitive to be done by automated processes. In those cases, we still need manpower.

It does help to identify which tasks can be automated based on Kryon functionality, until you have close to 50 multiple tasks from one client. As soon as we automate any one of our top volume drivers, we try to understand how we can automate the next one orthe next highest volume driver. We have tried to use Kryon's functionality to the max, but still there are some limitations that don't allow us to automate all the tasks. E.g., anything that involves free form text is a major drawback. We use forms which get their data from our customers along with their account details. So, their form details are always the same. They don't change the fields, only the values are different. If it were an email, every customer would use their own words to describe the problem. It's difficult to write simple logic that is common for all types of words. I think free form text requires artificial intelligence. However, the lack of AI is not a big issues.

Another major drawback is OCR. We are not able to read scanned documents correctly in a reliable way. There is always some margin of error. Some of the processes require us to read scanned documents, and you need to ensure that it is 100 percent accurate. Without that level of assurance, you can't automate such tasks.

Our client uses Citrix NetScaler Unified Gateway. It is a virtual machine. All the tools that we use run from the client's location and through a virtual machine called Citrix. It is projecting the remote screen onto our screen. Kryon is not able to identify individual applications behind Citrix. All it makes is a screen by taking the image. So, Kryon's functionality is limited to screen reading. Because of this, we are not able to take advantage of the Windows functionality or web server functionality. like browsers. They are not able to identify whether it's a browser, etc. It can just read from the screen. Being able to identify applications inside Citrix would be a huge advantage for our processes.

Their logging features are minimal. 

Reporting-wise, there are some reporting options, but I don't think they are very practical from the point of developers.

We haven't had any instability. It is very stable.

So far, the upgrade process has been smooth, but it does take a few hours. The upgrade process could be better. Right now, it takes a few hours for them to set it up. We must wait to have a shared meeting. They have to wait for us, and we have to wait for their availability. It would be better if we don't have to wait for them, and similarly, they don't have to wait for our availability.

Everything is managed by our console and the Kryon admin. All we had to do is get a license, add the system name, and the bot is simultaneously up and running. So, stability is very simple.

We have two types of roles: developer and tester. Developer does the coding work and shows new tasks are deployed. Once they are deployed, the tester's work would be to ensure the tasks are running correctly. We have a license for an unattended bot. However, because of the Citrix issue, we still need to have at least one person on the floor to monitor the bots in case anything gets stuck, the tool is not responding correctly, or ground does not direct the total Windows, etc. 

We have seven people covering all the shifts 24/7. Apart from developers, we have four testers. One developer is enough for development and maintenance, but we still have three to ensure that all of our shifts are covered. Thus, we can work on multiple task at the same time.

The customer service is pretty good. The only problem is availability. Because of our high transaction volume, we have to give a scheduled time to them. Similarly, their experts also need to schedule among other customers. So, there is no dedicated support, but I know they are available and very helpful. It just takes a bit of time to contact them with both of us trying together. On average, it takes three or four days to schedule something with the customer services. 

If it is an emergency that makes our bots go down, they will make special arrangements with us. They make sure that they are available immediately. We haven't had downtime for more than 24 hours, so far. The customer service is great in supporting us.

This is our first RPA solution. We did try automation with Visual Studio, like encoding, but it was a failure. We thought RPA would be a better solution: easier to implement and error free. It made sense at the time, and it's still helping us out.

The initial setup was straightforward. 

The deployment took a couple of days: One day to set it up and one day to review.

We just have one environment with multiple bots. We straight away went into production. We didn't have a testing environment or equivalent.

There were Kryon people who took care of everything. They just had to arrange the requirements. Once that was done, they were able to take up a remote connection and set up everything. They were helpful, ensuring everything was properly working and up and running.

At the beginning, we had fewer bots. So, we just went straight into it without a plan. We asked the Kryon team to set up a server, and they did. From there, they licensed us the bots. Once that was done, we started coding and straight away implemented them. Anytime that we have required an upgrade, we will just add additional bots.

If they need to upgrade the version, they will let us know that a version is available. We give them a suitable time and they will schedule a meeting to upgrade it remotely.

Error rate and manpower has been reduced. The error rate has been reduced almost to zero. Though, sometimes, some of the tasks are done better with humans than Kryon.

We are not exactly saving money at this stage, because we have invested a lot in Kryon. Our transaction volume and cost that we are receiving has not yet equated in a profitable way. We are moving to a more profitable way going forward, but it will take a bit more time. In maybe another year or so, we will see some improvement and ensure that this solution is profitable.

It saves our business analysts a couple hours per day.

Our workforce management (WFM) team is managing the licensing costs.

Kryon was our choice. Our project manager brought in Kryon team for a demo. Once we saw the features, we did a test with their training specialist, then we were convinced that we could utilize this for our requirements. We didn't look at any other options at that time.

It is a good solution if you're not using any virtual machines, like Citrix. 

It would be better if you get a demo or automate a simple task using Kryon. Get them to show you a proof of concept so you can understand what other challenges that you will have rather than blindly implementing it. Definitely, get a demo to see how efficient it is. Seeing it in action helps a lot.

We are not completely moving to a digital transformation. Even our management doesn't agree with 100 percent digitized solutions. They still want some level of human involvement, as well as for auditing.

The humans in our company have been concern about the robots taking over their roles. The robots take up most of the redundant tasks and focus on those. This ensures that our agents do the more complex ones or the low volume drivers. The agents do all the ones that require more logical reasoning, installation processes, or secure processes. We train our agents on these tasks and reassign their skill sets. We give them more training, giving them more complicated tasks. We aren't trying to lose our agents, even though manpower reduction is there. We just trying to retain them, but for different types of tasks, ones that require more human involvement and thinking.

We don't use Kryon Process Discovery or any of their web related services.

Automation takes up most of the walling that we get from our clients. Ground is being used extensively. However, the limitations are caused by Citrix, which is making us rethink our strategy sometimes as to whether we will be able to increase with the product. We want it to be faster and more reliable. We want to ensure that with any errors which occur, it is able to identify those errors, and it's able to rectify them or at least log of them. We want to take a look at them or notify people. Currently, only because of the Citrix issue, we are constrained. We might need to take a look at another software that supports Citrix more efficiently. Currently, there's no plan to increase usage, but it is part of our major usage as of now.

We use it for rapid process automation, but we also have Process Discovery. We use it for billing and collections, business administration, and insurance.

We have some idea of what we wanted to start with. We have been able to expand on that since embracing Kryon a bit more. We originally went into this solution knowing there were some processes which were extremely manual and wanted to take on automating. Once we got into using more of the advanced commands, we got through with some of our first, second, and third wizards, then we were able to take a step back, and say, "Here are all the functions that I've now learned to work with. I want to put them into higher level of development." We were able to expand the idea of something very simplistic, a three or four-step process, then move it over to a 50 or 60-step process. Because of those advanced commands, we could condense them down, which was something we didn't know at the time would be a reality.

Kryon has helped our existing workforce embrace the digital transformation of our organization. We now have people who are more interested than ever in moving over to digital processing. We are able to focus on key components of the business which can't be processed through automation.

We have seen some significant drops in employee errors. However, your data is only as good as what you receive. Errors have reduced by 80 percent based on the processes that we have automated by the sheer fact that we don't have people touching so many of them.

We have been able to streamline some processes just by using RPA. That has improved them.

Its ability to work with multiple platforms within the same application or "wizard". Some of the SQL functionality has also been extremely helpful. All of our platforms are homegrown. We don't use an out-of-the-box software, which makes our availability to using RPA software suites pretty limited. Then, you have a product like Kryon which is flexible. We use PowerBuilder as our application building codex. Kryon adds flexibility when we have the functionality of SQL, where we can take sets of data out of the back-end and run complex computations or do a bunch of data validations inside the wizard. It can save us sometimes dozens of steps, then if we were to try and do those same reviews using the user interface completely. The balance that we get from using Kryon RPA, alongside being able to screen scrape and frequent screen, gives us an advantage that we haven't had previously with any of our other attempts at robotic process automation.

Kryon Process Discovery is a very exciting thing. We are rolling it out to approximately 100 VM machines, but we will be using it comprehensively for the next few years, as long as we can get it rolled out here soon and start gathering more information. It's been a very exciting thing for us here at LTCG.

We haven't finished rolling out Process Discovery. We only have it on three computers right now for the test environment. However, one of the most complex tasks that we are using two full-time employees to do was have it record and monitor these employees, along with all its variations, and how they are working through a process. We then exported that from Process Discovery into Studio. Now, instead of starting from scratch on a process that a developer wouldn't know, we have a framework and outline on how to make that work from end-to-end.

The read from screen functionality needs improvement

We still do a lot of stuff in the user interface. Finding UI information and split UI need improvement.

I would like them to add more functionality from Excel, especially when you pull data from Excel.

We've had a lot of good success using this solution for the full-cycle of automation from the discovery of processes to turning on the automation and scaling it up. We would like to see having a little more specific documentation, or some of the examples be easier to find. One of the big things that we get directed to now is the Kryon Community page, but a lot of that wasn't in existence or publicized when we started doing our training and education. Now, we're stumbling through using it. For the majority of the time, we have either had to try and interpret what the instructions meant or do a service desk ticket.

I have had two people go through the online training. My feedback would be that they need to focus a bit more energy on that. I would like to see that online training be a bit more comprehensive in the projects that they create, so we can say, "Here's what we have," or, "Here's what we need." I don't know if maybe they should sit down and try to develop "training" documents as well. Or, like dummy wizards, where you have to copy and paste this wizard, start from scratch and learn these steps, then you put it together to make it work, which would be similar to what we did with the in-house training. 

They could add a bit more to the online training too, since it's still relatively new for us. We don't have a "dedicated" team of people who do this. This has been a learning experience, because we only have a limited number of people who can dedicate hours to it.

It is a very stable process. It has been a learning experience for us. We have learned to make some changes in our system to add stability that users were experiencing. They were experiencing the same instability issues that we were having. RPA shed that light. We've made some changes structurally to our IT and business processes to avoid that in the future.

We have seen bugs and had frustrations. When we've done software upgrades, or opened service desk tickets, things can get frustrating because of a slow response. There might be a system outage, where we weren't informed of it until everything at our site went dark. So, we have had growing pains.

Scalability is still a possibility for us, as we will probably need more of the solution in the future. I don't have any concerns about scalability at this time. We do have plans to increase usage. 

We have two attended machines, because we have such a low demand for it right now. However, we do have nine unattended machines that run daily. We average about 1200 to 1300 wizard runs a month.

We have five developers, all from different subsets of the business. We have some that specialize in finance, account management, or those of us who came from more of an IT background (or a more structured IT role). We have a good mix of of SMEs with some IT mixed in there.

Kryon's technical support is very good. They made some core changes that have improved the solution over the last two years.

We have used other RPA tools previous to my time at LTCG. None of them were successful after the original deployment. Therefore, we decided to wash the project. While I don't remember the name of the software, the reason they were unsuccessful is because of the language that our user interface is built in.

The initial setup was complex for us, but that was, in part, from the way we operate at LTCG. I wouldn't put that on Kryon.

From start to finish, the deployment was four months.

We did the deployment all internally.

We do upgrades three times a year for both Process Discovery and Kryon RPA. Essentially, we have a structured team set up who opens up in a project, then we start reporting against the project. We try to get all the requirements built, but it all runs through me. So, I run it as a type of the project manager. Then, we deploy the upgrade alongside the customer review team. It is not as rigid as some other projects should or could be.

We currently have four total users from IT, who assist us in maintaining the Kryon server, Process Discovery server, and upgrades for deployments, which includes security and overhead. There is also my role, which is just performed by me.

We've more than broken even over on the license. Year to date, we are at $120,000 in savings.

We have been able to alleviate two FTEs, which was a big savings for us. We were able to reuse those resources in other locations. It is over 5000 hours a year in total savings.

We were able to reduce our processing speed in time by 65 percent. That is just simply by using a robot versus a person.

Licensing costs are about $100,000 a year without any additional costs.

We had requests out to four vendors: Kryon, UiPath, Automation Anywhere, and Blue Prism. Kryon did not end up being the most financially inexpensive, but it did make the most sense based on the ability of having business users develop, not IT people. The product bridges the gap in terms of ease of use for business users with no tech background, compared to a UiPath or Blue Prism. With those solutions, you have to be a .NET developer to use them. Kryon allows people who are business-oriented people to use it.

Understand that you need to have a very well-documented framework of what you plan to automate. Not necessarily the idea of, "I want to automate this task." But, as a company, don't be narrow-minded to believe that these are the only tasks that we can automate. You'll find that there are a lot of groups which are doing things that you may not know of that you can automate very quickly. Be very open-minded when you start working with the solution, because you'll find that a lot more doors are open than you originally anticipated.

As with anything in software suites, you are always going to have challenges where people didn't know something was a function or didn't know this is how that worked. Kryon has a good start in trying to bridge that gap between the developer, who would look at something, and go, "Yup, I can pull a lot of this data from SQL, and I just need to click these buttons," versus someone who doesn't have a technical background.

There is still some growing to be done. It is necessarily the product that has been the problem. It has been necessarily some of the responses that we have gotten from Kryon itself. 

We took all kinds of mindless operational processes, things we were doing over and over again and which cost us a lot of work time every day, or week, or month, and scheduled them to be automatic, with no human hand in the process.

We have a lot of examples. We make loans, although we are not a bank, for various purposes. Sometimes, people don't pay us back and the loans go to collection. We have to start all kinds of processes via lawyers, and when we transfer a case to a lawyer we have to prepare it. All the preparation for the lawyer is automatic now. All the letters for the lawyer with all the details about the loan, about the collection - everything is automatic.

Also, for each customer whose debt we transfer to a lawyer, we have feedback to our core system to update all the data in the system again. So all the data about the customer and the debt comes from the system to the lawyer, and feedback from the lawyer comes into the system. And all of this, of course, is connected to the loan itself, to the customer. Everything is aligned.

We are a digital company. We very quickly embrace all kinds of digital transformation. Kryon was just a part of that. We have engaged in digital transformation in many ways in our company. But the adoption of Kryon was very quick, and that is its advantage. Because it is a very quickly and very intuitively customized system, it helped us to adopt it through users who are not technical users. It really helped us to put a lot of automated processes in the system and adopt them very quickly. Now, my organization wants more. They say, "How did we live without it before?" It really helps us in our day-to-day processes, the ones that are not so complicated, not so involved, that we do over and over again.

Efficiency has increased. If robots are doing stuff we used to do, this increases the efficiency of the staff.

All our users have no technical background. But Kryon is really simple and intuitive. Our business adapted very quickly and easily. This is the main thing and it's why we love the system so much. It's why we are always trying to put more processes into the system and make more use cases: because of the simplicity and the intuitive nature of the system.

Our original plan was to do something like two robots, and a few processes, but because it was such a success in the company, we expanded it. We have 11 processes. The eleventh is due to go live in about a week. Some of them are not complex, some of them are more complex. It depends on the process itself, the amount of time, the amount of integration, if there are dependencies on another system.

In terms of plans to increase usage, for now we really want to see how the day-to-day is going with all the processes. More processes mean more licenses and robots, and we have to do ROI as the next step. I would guess we'll do more, but it's already a lot to have 11 processes in a year with four robots.

We, ourselves have not used Kryon's customer support. Maybe our third-party uses it on behalf of us. I don't know.

This is our first RPA solution.

The initial setup was straightforward. It was very quick, very understandable, very open. If we had problems, they were helpful. They assisted our third-party company. It was very easy to work with.

Deployments depend on the process. We have been working with the system for a little less than a year. After about two months, we had the first process working. It's really quick. When I say two months for the first process, that means we sat with the customers, understood what they want, how to do it. We had them test it, we launched it, we optimized it in production. The whole timeline of the process was handled in that amount of time.

We asked our organization to set the priorities. We asked for a quick win, meaning something very small and very painful, or something which was taking a lot of time. That enabled us to win their appreciation and reduce the resistance to change. Some people may look at it as a robot is replacing me. We handled this too by making them a part of the implementation process. This way, they wanted it, were engaged with it, and wanted to do more. It gave them something that they hadn't seen before. It gave them a feeling of success. It's very important, through the process, to feel like you are succeeding in doing something new in a very short amount of time. The people involved have to see we're not really replacing them, and that it actually helps them to do more, to do better, to do things that have work quality to them.

The people using Kryon are from three departments: collections, services, and operations. Not everyone is using it, because we're uploading files to the system. There a few people in each department who are doing it. Overall there are about ten people involved with it, but it services the whole department. There are the people who operate the system, and the people enjoying the fruit.

Even when I purchased the license, it wasn't via Kryon. It was through a third-party. The product is Kryon, but the customization and all the agreements and the buying process were not through Kryon. It was with a third-party.

The reseller is HMS. All our connections to Kryon are through this company. All our processes of examination and solutions were through them. We are very pleased with the job they have done, with the service. They are very good and they helped us a lot.

But these days we are transferring all the knowledge, all the data, and all the operations of the system to our people, the employees of our company, so that we will be able to do it alone. The first year was through this third-party, and we have their support. And now our main goal is to be able to do it on our own.

Kryon has saved us money. We measure in terms of people. We haven't increased our employees in those departments, and we can say that we have saved nine employees, nine people we haven't had to hire.

I would expect that in the first year there is no ROI. It has to be measured over three or five years.

I wasn't part of the process. I had a colleague who did it.

It depends if you are doing it by yourself, with your employees or, like us, through a third- party or someone who knows how to work with the system. If you're doing it through a third-party, there is no problem and they have all the knowledge, all the data, all the know-how about how to do it. If you are doing it with your own people, training is mandatory and Kryon has it. Some kind of on-the-job training, or some kind of support, is necessary to be able to implement it quickly and the right way, because there is a right way, a way to do it properly.

Kryon was not involved in helping us find and prioritize processes that are ready for automation. We did so. They were not part of this process. We came up with the processes, we talked about them, not Kryon.

I'm not the one who uses the system every day. I'm not the one who uses the customization. We go through a third-party which does all the customizations for us. I can't tell you which part of the system I enjoyed the most, or what I'm using because I have a third party for that.

The primary use case is for back office processes.

It has improved our organizational process in inbound and outbound tourism. The previous process was very complex and took at least a day for the users. Now, it is fully automated and saving a lot of hours for our back office.

The product is very useful for our organization. The process takes approximately a month.

Our organization has nothing between the digital and back office processes.

Because of this product, we started to look for more processes to deploy.

The most valuable features for our organization are the automatic processes which save main power in the back office.

From our experience, the product is not suitable for end users.

It is a very stable product.

It is a very scalable product.

The product is used very extensively. We have plans to increase usage.

All users can use the processes.

We require two staff for deployment and maintenance.

The technical support is very good.

The vendor's customer service is very good.

We didn't use a previous solution.

The initial setup was deployed by Kryon.

Our implementation strategy was evolution strategy, process after process, and be the leading business user.

We used a third-party, HMS, who has very good knowledge in the product

There is no doubt that there will be ROI. However, it is too early to provide data.

This solution has saved us time when launching new automation processes, but it is too early to give the amount of time.

There is not enough data to determine if the solution has saved us money, business analyst hours, operational efficiency, or reduced employee errors.

In addition to the standard licensing costs, there are manpower costs.

We would recommend it.

We don't use Kryon Process Discovery.

We use Kryon in a number of use cases. We have done a lot of work in the insurance industry, especially client-onboarding. We are also working on AML, anti-money laundering. Another use case is data extraction from invoices, using the Kryon platform.

To give you an example, we worked on a client-onboarding scenario. Client-onboarding, when run manually, was typically taking about 45 minutes for just one customer, because the process is so lengthy and because of the amount of information required. In addition, it was updating four systems and there was work done to match the systems, which required a migration piece. Now, with automation, we capture it once, in one system, and then onboard this information to two or three other systems. It now takes a maximum of about eight minutes, compared to the 45 minutes of work when it was done manually.

It has definitely also helped our workforce embrace digital transformation. We have implemented this with onboarding processes, email processes, and the like. It has now spread to multiple LOBs and they're talking to us, including HR, finance, and more.

The bots result in a lot of effort saved and that means we don't need to hire people to do certain jobs. It's saving money on FTEs. I estimate that when we run a business use case, the typical savings are four to five FTEs per month. In terms of business analysts' time, out of eight hours, typically four hours are saved. Operational efficiency has increased more than 50 to 60 percent. Finally, it saves us time when launching new automation processes, by about 30 percent.

The best feature is its reporting. The core features of Kryon are the best. 

In addition, the number of commands it gives us to edit and modify is really good. 

It also captures screen activities and plays them back. I'm a technical guy, so it's very easy for me to do it. If I imagine giving this to a business guy, it is really amazing, because he knows what action he is going to perform.

With respect to web-based applications that we have, Kryon may not be able to do certain things in terms of technology and support.

Also, there are limitations on integrations with other platforms like ServiceNow. There are some issues integrating. It's not a really an open system. The product, its design, etc., is really good, but they have to look at the openness, how to integrate with other products which are available in the market, as well as with our own solutions. You can do integration but it is not so easy. You have to build certain things to integrate. It's not like an open API is available. It's there but it's not really open compared to competitors.

The only challenge today is that when we migrate to a new version, there is a lot of work. We need to roll it back. Once migrated, we cannot roll it back easily. There are a lot of things that need to change. We've asked Kryon to build a complete package so that migration can easily happen from one version to another version. 

For example, 5.1 to 5.4 was really a nightmare for us. It was more to do with the number of assets we had. When they changed to 5.4, with the new enhancements, some of the scripts were failing after we migrated, and we had a whole list of issues. We had to reconfigure certain elements. It was effort. It was not an easy migration.

We are now doing close to 20 processes. It still works fine. There are no issues from the scalability point of view.

Technical support is there in some of the regions. In APAC it is good. One or two years back, it was not there. They've improved since then. They are able to support us if that is required.

The initial setup took some time because there are a number of components. There is a server, Studio, etc., so it takes some time to set up properly. But once it is set up, it's easy to work with. But the initial setup requires some time.

Setting up a server typically takes three to five days. We go through a process where we regulate things, we make sure we validate the software, and we that we have approval. 

Our implementation strategy was to first set up a pilot. After the pilot, we wanted to go full-blown. That's when we looked at infrastructure for development, testing, and production. We then started bringing a lot more LOBs in, to grow and develop.

We used Kryon consultants, and some of our team members also got trained and certified so that we could take over that piece. Initially it was a joint effort and after that we took over.

Our experience with Kryon consulting was good. They follow certain guidelines, they don't allow any unwanted consultants to implement or do anything. They make sure consultants are certified in the product and that they have experience. That was good. That's how they start with all customers.

If we look at the number of FTEs saved, there is definitely ROI from those savings. In fact, we are collecting metrics on that now, to know how much value we've had. Over the three years we have had close to $300,000.

Our licensing cost is close to $80,000 US per year and that includes the server, Studio, and both attended and unattended bots. There are no costs in addition to the standard licensing fees.

We evaluated a few solutions but Kryon was the platform we chose. We evaluated UiPath and Kofax. We found Kryon to be a good platform so we engaged it. It is easy to use, no integrations were required, there are no plugins to download. Our platform includes mainframe and client-server.

At the time we were evaluating, UiPath was not really working out well. If we were to compare now it's a different scenario, but two years back it was a nightmare.

My advice is to follow the right set of instructions and best practices, even before you implement automation. Look at what is available, at how you do it. If you don't follow those instructions, you may find it difficult, but once you know exactly how to use it and what to do, it works. Have training properly done and after that start looking at implementation.

It's really good for end-to-end RPA. The way we work is we do a discovery manually rather than using an automated discovery process. Once we identify a process and we run through a complete lifecycle of it. We then work on the design elements, how to run the exceptions, etc. We make sure that UAT is done, that it is tested well. We then make sure that the business users accept the process, how it's going to work. We then validate the bot, make sure we get a sign-off from them, and then we go to production. We do one week or two weeks off thorough checking on production to make sure there are no exceptions or issues. We then hand it over to the client to run it.

In terms of the ease of use of Kryon for business users with no technical background, that's a key area. What we say to them is, if you're not familiar with Kryon and you want to automate, there is a basic, fundamental, one-day workshop. It will give you at least an idea of how to record, what the options are, what you should look for - the key things to learn about some of the elements of the Kryon platform. Then they're good to go. I see that users are then happily recording things and playing them back. So Kryon provides ease of use where they are not really struggling. If somebody knows Excel, that person can easily run Kryon.

We have business users and we have some developers. It's a small team of five to eight people, including the business users. In terms of deployment and maintenance of Kryon, we currently have a very small number of processes. There is an agenda to grow big. We're looking at more than taking more 30 live so we are bringing in external consultants to help us do that job. We want to keep a lean team right now, because once we go live we will need to do more of the production support and maintenance of the bots. We will only do small-scale development in-house. If it gets to a complex level, we will get a team of consultants to help us. In terms of infrastructure, we have one guy dedicated to that right now.

I would rate Kryon at seven out of ten. There are the migration issues and they need to support web-based apps.

We have two primary use cases. One is the back office. We're a bank and we are automating some work of the bankers - mostly manual jobs like typing Excel data into our legacy systems and the like. The other thing is automating testing. We have really difficult scenarios involving both legacy and web systems. We hadn't found the right tools to take testing all the way from start to finish. But we have found Kryon very effective in that direction.

One way Kryon improves the way our company functions is in testing. Previously, we didn't have full coverage and we couldn't run a full regression day by day, or after major activities such as updates. We had to do it all manually and we didn't feel confident. Now, it's a completely different thing. We're trying to build a strong regression area where we can run a full regression of all our systems by clicking a button. We're not there yet, but we're heading that way. It's going to be a complete change in the way that IT acts because it gives us much more confidence.

One of the main features is its ability to connect into literally everything we've got here. Some of that was easier; some of it took some extra labor. But all in all, it has the capability to connect and to interact with almost every system that we have. That's the main feature. 

The next feature is the triggers. It's relatively simple to activate it. You can activate it via Control-M or via email. It has a lot of built-in triggers which enable us to easily activate the jobs.

The third is the support. We have great support from the guys here. It's not the product itself, but let's call it the "ecosystem" of the product. We have a strong product owner, and they respond very quickly to every question we have. That's a good thing.

The cognitive part, the OCR could use improvement, but I know it's on their roadmap. 

We need stronger governance to know, when a transaction is done, whether it worked or failed; strong logging. That would be helpful.

It's pretty stable. I can't think of a major crash.

We're not there yet, regarding scalability. It's fairly easy to purchase and make another robot, another machine, but we're not there yet. We're not at the limits of use of our first one.

Selenium was only good for web applications and most of our business processes involve more than just web applications. So if we wanted to run a complete test, end-to-end, Selenium didn't really help.

The initial setup took a while because we're a bank, so we have all the security requirements. It took a while but the setup was not very complex. The go-live took a couple of weeks but that was not entirely because of Kryon. It was due to the bank system itself, the firewalls and security.

Our implementation strategy was to go to the back office. We took ten nominees and we tried to pinpoint the one that would be most useful yet which was not too complicated. We gave it to Kryon as a PoC. They came and we said: "Let's take it step by step. Let's see if it works." If it did, we would try another one. We would then try to spread it among our core systems. We would connect it to each core system and have at least one active job in each of them. From there on, we made set up a center of excellence within the bank for automation, and people come to us now and ask us.

A Kryon consultant helped us with the primary deployment, but now it's our own team. Kryon guided us. We went to a three-day workshop with them where they explained it and gave us the primary technological understanding. Our experience with Kryon consulting was that they were helpful and professional. It was okay.

We're connecting with on a daily basis when there is a problem. But we have since made our own team.

We're a relatively small bank. So even if we can automate a decent scenario, we still don't have a lot of users or transactions. So the ROI is going to take a while in that area. In the testing area there is a good ROI, because we're now capable of doing things that we couldn't before. Completely. It's a game-changer.

For example, in the scenario of making a loan, part of the process was typing things into our legacy system. Selenium, the solution we had before, just couldn't do it. We had to abandon the goal of automating the scenario, and now we can. It's a game-changer in that respect.

The truth is, when we brought Kryon, we didn't think about automating testing, and they didn't recommend it. It was not meant to be a Selenium or testing tool, but we thought it could be useful, and it turned out that it was.

We did not evaluate other vendors. We quit using Selenium and, once we got Kryon, we said to ourselves, "Why not try to use it in place of Selenium?" It turned out to be much more useful and much cheaper, because we already had the license so we can use it whenever we want. Selenium was expensive and it only gave us certain aspects. So all in all, going with Kryon was a good thing to do.

There is a vast field of RPA tools. You have to know what you want to do and how to add value to your business. You need to see if what Kryon gives you is the best fit for you. For us, as beginners in the field, it was good, because of the support and the willingness to help us and to be cooperative. That was very helpful at the beginning. So you have to evaluate which step of the RPA lifecycle you are in. I can tell you more, in a year or two, if I'm satisfied when I am more advanced. But for starters, it is a good decision.

In terms of using the solution for the full cycle of automation, from the discovery of processes to turning on the automation, and scaling it up, it's a little bit early to say, because we don't have a lot of experience. And I can't compare it to any other thing that we have, because we're really at the start of it. But so far, it has met our expectations. I didn't think it would go as fast as they described it, and it didn't, but it was fairly rapid, and it has its ROI. All in all, good.

It's not for end-users, absolutely. It's not that. For developers, it is interesting. We didn't actually use developers to work with it. We had more, what I would call an "implementation guide." It takes knowledge and it takes time. There are a lot of technical issues, not only because of Kryon but because of our system and the integration between Kryon and our system. It's definitely not for end-users, regardless of what anybody says. It's not. But it's fairly decent for developers. 

We have our four developers who actually touch Kryon. We have two-and-a-half to three people who are dedicated to deploying and maintaining it, and another one comes and goes. We definitely have plans to increase usage. At the moment we do about 1,000 transactions each day, but we want to get do more.

As for helping our organization embrace digital transformation, we're heading that way. It's only the start, but we have a good vibe here. I could answer that question more comfortably in a year. But I see the way. I see the light.

We had an outside advisor, not Kryon itself, to help prioritize processes that are ripe for automation. We preferred it that way. Maybe Kryon could have given us that service, but we preferred to take an outside advisor.

I would rate Kryon at eight out of ten. It's not as rapid as they describe it and it has its limits. We have met with Kryon a couple of times. The guys were very helpful and said, "We'll bring that into the roadmap," etc. But we hit the limit of the product. For starters, we expected that to happen in year-two or year-three, not three months after trying it. But all in all, it has been a good experience.

We have legacy software in our company. Some processes in our company are being done manually. There are very routine jobs, processes where people are sitting in front of a computer and typing data. This software, Kryon, enables us to make these processes more automated.

We program the software, we run the use case with the software and now, instead of things being done manually, they're being done automatically. It's helping leave all this old legacy software which doesn't have APIs. We wouldn't be able to do it otherwise.

We cannot get into this legacy software. There are no APIs. It would cost a lot of money if we wanted to develop something like an API. This software enables us to overcome this API problem, automate things, and do it relatively quickly. It's low-cost development.

We're a bank. We get money transferred to the bank from other banks, but some of the data can be wrong. We know it's money coming to our bank, through a money transfer system in Israel of which we are a part. But if we cannot recognize which account number it belongs to, regulations require us to send the money back to the bank that transferred it to us. This happened every day. Until we had this Kryon RPA solution, there was a person sitting in front of a computer typing these transactions into the legacy system. It was all manual work and the person doing it would work, say, two hours a day doing these transactions. Now it's done automatically. 

So it's not just that we're saving the time of this person having to do this typing, but we have also improved this specific person's job satisfaction. She doesn't have to do this boring, hard work. Not only are we saving valuable time of our employees, but there is added value, like fewer typing mistakes.

The recording feature enables us to record what we're doing, like typing or clicking the mouse, and to identify objects on the screen. We basically teach the program how to type, instead of a person. That's the most powerful feature.

That's valuable for us because it's the only way we can automate this process.

I would like to see a better OCR solution. That's the main thing: identifying unstructured data, like all paper documents and data from pictures. 

Also, because we are in Israel - Hebrew is a hard language - we'd like it to better handle Hebrew.

We had some issues, but it's relatively stable. We didn't have any major issues. Their support helped us a lot. Some of the issues we had were because we didn't know how to work properly with the product. But it's working and it's doing its job. I'm relatively satisfied with the system.

We don't yet have a lot of processes in production, so I don't have experience with its scalability. I don't see any problem, why the product would not be scalable. But we don't have a mass of processes, so I can't say anything further.

So far, we have automated six processes, about one process a month. Of course, we have plans to try to put through two processes a month into production. We're planning on doing tens of processes in the next year. We want even more, but that depends mainly on us.

Technical support is very good. They answer fast and they know what they're doing. We have had a very good experience with them.

We used nothing before Kryon.

It's hard to say whether the setup was straightforward or complex. I think it's quite simple. But because of all the security requirements for data at our bank, we couldn't do it in a straight way. We had to go a very different way, so it wasn't so straightforward. I don't know if it's our fault, because of all the security issues we have, or if it's a product fault. Let's put it at 50/50.

It took about a month-and-a-half, from the beginning of the deployment with Kryon, until we solved everything, and we could run our first process in a production environment.

Our deployment strategy included internal meetings, trying to map the processes we wanted to automate. Second, we started negotiations with Kryon for buying their product. Then we started learning the tool and how to work with it. At the same time, we started installing it on our server in our company.

After we finished the basic installation of the development studio, we started developing our processes. That was the month-and-a-half. We were installing the program and dealing with all the security issues. And at the same time, we mapped our processes and development.

After we finished with them, we continued mapping and identifying the other processes in our company. Kryon has been advising us, not only about installing, but also by giving us best practices on how to map and how to identify the processes that we can automate in our company.

Kryon assisted us with the deployment. It was a very good experience. They were really committed to our success. They were very informative and helpful. They solved the problems and the issues we had to deal with. I have a very positive opinion about them.

We have definitely seen return on investment. We are checking it all the time. By the end of this year we will have returned the investment, and we will start gaining more. Most of the money goes to developers' salaries, people working at the bank, rather than the licensing. Including the salaries, we expect that by the end of this year, we'll return the investment.

For an unattended robot it's $6000 a month. Right now we have three unattended robots.

We checked out Blue Prism and Automation Anywhere. Even though we have deployed Kryon, we are still checking other solutions. Maybe they will be valuable in different processes. 

We decided that Kryon would be the best, mainly because they have the most installations and production in Israel. They have quite a lot of experience.

I would highly recommend getting a commitment from the vendor - and not only from Kryon. It's hard to get the vendor's commitment and to know, when you sign the agreement, what the SLAs for dealing with your problems are, and how committed they are to you as a client.

The second thing is that more important than the source of the RPA solution is the way your company handles the automation of processes. It's a very big issue in a company. Employees are scared they will lose their jobs. It's something you have to deal with no matter what the RPA solution: how you manage these changes in your company. Kryon and others have a very methodical way to do this by creating a center of excellence, etc. It's very important to do this even before you choose your vendor.

You need to address peoples' fears, that's the main thing. A good organization will not send people away, but will find them more valuable things to do, instead of the very routine things that RPA can do instead of them. You have to address many people at many levels, that this is something that you have from now on. Every new product, everything you have, they should know that you have an automation tool that you can use. It's very powerful. It's helping make things more accurate and faster. 

It's a change, not just because people fear losing their jobs, but in many other aspects. Even management has to know about it, about the capabilities of these tools.

The users are developers. We have two developers and I am a system administrator. This program is for developers who develop the processes. Once the processes are developed, we can replace business users in certain jobs. The three of us, and perhaps two others who are administrators of our VM machines and who deal with security issues, handle deployment and maintenance.

We mainly use it for creating automated processes from previously manual processes, to make existing processes faster, better quality and more efficient. We currently have three processes implemented in production and the fourth is going live next week. It's not heavily used, so far.

The first one is small. It just enters the US dollar currency into our ERP system. It's a daily task each morning. The second one involves an external, third-party systems from which we export a report and import it into one of our systems. It used to be done on a daily basis by an employee and now it's being done automatically. The third one is an automated delivery note. One of our suppliers, provides our tobacco products with paper delivery notes. So now they send us a daily report and the robot enters the delivery notes into the operations system. The fourth one which will go live next week, will upload bank notes of returned payments into our financial system. That was another manual process that will be automated.

The currency automation saves us around five minutes per day, but it has to be done every day. For this one, the amount of time is irrelevant. It's more that there are many processes that rely on the currency. So if it hasn't been done or is done late, it can delay other processes. So the value here is more than how much time it saves us. The second one saves us approximately five to ten minutes per day. The third one, the delivery note process, is more difficult to calculate since we have approximately 200 points of sale. Each one has one to two deliveries per week and it takes five to 10 minutes for each point of sale to create these delivery notes manually. So it saves us 2,000 minutes, about 1.5 times a week. The last one, the one that is going live next week, is more significant. It will save approximately a day per week for an employee.

As for operational efficiency, the automatic delivery notes is most significant. From the 200 managers, the bit of feedback that I have gotten is very positive. From the others, I have to admit that it's more minor.

Of course it has helped to reduce employee errors, especially with the delivery notes, since the correct number is very important. If you enter "11" instead of "one," a type-o, it's very significant because it is an expensive product. Definitely, in terms of user-error, we have improved on that a lot. Before Kryon, there were one to two errors per day, or about 50 per month. We found most of them later on and then someone had to remediate them. It has saved us significant man-hours.

Once I decide a process is suitable as a Kryon solution, the cycle of automation is quite quick. I learn about the existing process and I'm one of the two guys who program the Kryon environment. It's relatively simple. There are many details, but once you understand the concept it is quite easy.

I think our version is two versions behind. I just had a talk about it last week with our account manager at Kryon and we planned together to upgrade the environment once per year. In my opinion, today, if possible, it would be better to have it done automatically, like an application on your smartphone. Or even if done manually, the upgrade should just be "next, next, next," and it's upgraded, rather than making it a project to upgrade. In the digital era, that is one of the expectations, that it would be easier.

Besides that, it's all about functionality: What you can do and what you cannot do. I'm not very familiar with the competitors' solutions, so I'm living in the world or Kryon functionality. Sometimes I'm looking to automate something and it's not there. That doesn't mean that it's not possible.

In terms of additional features, the sky is the limit. For example, we are working with Oracle ERP. It would be great if there were built-in functions or commands to integrate with the Oracle application, and not everything through capturing screens and going from there. Currently, there is only an integration with Office, mainly to Excel. I understand that Excel is much more popular than Oracle in terms of use and in terms of integration. For an organization that works with the Oracle application, I would love to have even a plugin or a tool kit for that - maybe to SAP as well.

There was one day that Kryon had a problem to do with a certificate change or something like that. The whole Kryon environment was down. Aside from that, it's been quite stable and works smoothly on a daily basis. We haven't faced any problems.

We haven't explored the scalability yet. There is room for many more implementations on the one license that we have.

I'm working with the technical support on a few issues. For the issue with the certificate, I sent them a case and they replied immediately saying that it was a global issue and that it would be fixed in the next couple of hours. And it was. Overall, on a scale of one to five, technical support is very close to five. Over the year I have had something like five or six tickets. One of them is ongoing + one bug reported.

As for customer success, we have an account manager. I think she supports all the local market accounts. She initiates meetings once per quarter. She's very approachable and cooperative. She's really great.

For the setup of the whole Kryon environment I was only involved in the framework, just to make sure that our system group prepared the server and installed the SQL server they requested, and to make sure they had all the permissions they needed, but nothing more than that. The consultants did all the rest.

Maintenance requires just my colleague and myself.

We didn't do it independently. We brought in EY (Ernst Young) consultants to do it. It went smoothly as far as I concerned. It was a one- or two-day workshop and it was done. It was really quick.

Thanks to them we have the Kryon environment. They suggested it and we brought them in to implement the first implementation, which is not being used anymore because we replaced the target system. 

They sent two consultants and one intern for the job. 

We haven't calculated ROI yet. I'm quite confident that in the long run it will demonstrate a return on investment. In the first year, at least for us, because there have only been three or four implementations, but nothing more than that, in terms of man-hours the supplier delivery notes is most significant. It's possible it has already given us a return on investment.

We have a yearly license. It's about $5,000 per year. There are no additional costs other than that a server has a license.

Initially, our CIO came up with the idea and brought Ernst Young in to implement it in our organization. In the first meeting we had with EY, they put two RPA systems on the table, Kryon and another which I don't remember. They gave the pros and cons for each solution and together we selected Kryon. One of the factors was that it's an Israeli company, so we thought it would be easier for us in terms of approachability, language and work hours. We believed it would be easier for us to use.

Take the training course. At least the person who is going to program the robots has to have some background in information systems in general and in more specific, operation systems, in programming and in Office, of course. He has to have a technical orientation, database knowledge would help him, as well as system analysis capabilities.

In terms of ease of use for business users, the only users are me and 2 other persons in the information systems department. Currently, we have only unattended implementations and no attended implementations which would require a user in the organization to operate it. As for programming it, it requires up-front training. The e-learning, at least at the time that we started working with Kryon, was not enough. Just the basics were there. When we tried to do some more complicated stuff, we had to understand it better. We took the four days of training. After that we started all of the implementations.

As for helping our workforce embrace digital transformation, I wouldn't relate Kryon to that, at least not yet. We are still not using it for digital processes or a digital environment. But we plan to do that in the upcoming weeks. There is a process to create a new customer, which today is very complicated. The last part is to just type the customer's details into the system. I'm thinking of using Kryon which would complete a fully digital process.

In terms of my rating of nine out of ten, there are many things that I'm not sure of. For example, it takes a while to launch the Studio, something like a couple of minutes. It could be that my laptop is not strong enough. It might be that our virtual server doesn't have all the necessary memory or CPU capabilities. It might be many things, so I don't want to say that it's only due to performance issues with Kryon.

We found a bug in a database trigger with Oracle Database. I know that it works mostly with the SQL server, but we are using Oracle, so that's another issue that came to mind. The fact is that we found this bug something like six months ago and it's still not in the new version. As far as it was communicated to me, it will be part of the next version. If that bug was critical for us, maybe I wouldn't have rated it a nine; maybe it would be a six or seven or eight. But, luckily for them, it's not highly critical for us. I don't know how they prioritize bug-fixing. I suppose that there are not too many Oracle Database organizations among their customers, at least not in our market. Therefore, maybe they prioritize this somewhere at the bottom. But for us it's a bug and we cannot use this functionality, which is required. That's why I took off one out of ten. Besides that, it works, it's stable, it has nice performance, and was, therefore, a good decision to go with it.

Automating a process involving SAP and Excel operations. Such operations require access to SAP TRX, export in Excel file, and running Excel macros.

Cuts time due to the building of a robot which runs during the night to perform time-consuming and tedious activities.

Recording user actions in SAP environment with field input and function activations, such as export to file, variants selections, etc.

I would improve the object recognition features, making it not linked to the screen resolution or the position.

No.

Setup is quite simple and not very expensive, but regarding licensing, I don't know.

No.

No.