Our initial use cases are mainly for finance. We are doing account payable, accounts receivable, reconciliation, and those types of things with the automation. In terms of accounts payable, we automate the invoice processing since it is an end-to-end. This means that the vendor will send an invoice to email, which will be picked up by the bot automatically. Then, it will extract the information from the invoices and post it to our SAP.
It is a web-based solution but hosted on our server.
The biggest driver was the cost savings. We wanted to improve productivity and save costs. Therefore, we gave most of the mundane tasks currently being done by a human to a bot. Some of the mundane tasks were reading invoices and keying in the data. We are talking about 15,000 documents every day. That is a huge volume that needs a lot of people. With the bot, it is just a fraction of the cost, because there is a huge savings in terms of manpower.
More for regulatory and audit purposes, we still require a human to approve it. Previously, we had the human to do it, then we had people cross-check it. Then, you have another layer of the approval. With the bot, we don't require two people. We only have the approval because we still have a person who does the approval, which we have to maintain.
The most important part is how easy it is to pair the automation. So, it is a canvas that is just drag and drop. You don't have to code, so it is a no-code to low-code solution.
It is good for simple tasks that we have done in the past, e.g., reading the invoices. A valuable feature is the document processing. Usually when we talk about document processing in the market, you just have OCR. Where once you extract the information, you need to program or do some type of data wrangling to actually get the value of it or process it. For Jiffy.ai, they have the machine learning behind it, so we didn't need to code one by one. For example, if you have 5,000 vendors who are sending you different types of invoices, then we are not talking about 5,000 invoices. We are talking about one vendor who has three types of templates, so that is about 15,000 documents to process. Even if you do OCR, you want to extract the information and code it to read this and that. So, Jiffy.ai has machine learning where we don't have to teach all the documents, instead we just need to teach it a few. Then, the machine will already know if it finds this type of information, then that is what it is. For example, the easiest way is the invoice number. Most vendors usually have similar wording: invoice number, invoice NO, and INV. However, in all 15,000 documents, you see that the vendors just play around with this wording. It won't differ much. Therefore, the machine learning knows because of this, you don't need to teach it all 15,000 documents. After about 10 documents, the bot can pick it up themselves and learn about it.
There are not a lot of vendors in the market who provide built-in machine learning. In the invoice, you have multiple things that you want to extract: invoice number, PO, and some other line items. With machine learning, we expect it to know what to extract from, by looking at different templates of invoices. It should know that this is similar. Even though you use the different wording across multiple templates, the machine should know that it is an invoice number. We expect the machine learning should be able to do this, and the Jiffy.ai machine learning is able to do it with 80 to 90 percent accuracy. So far, we haven't had a big problem in whatever the machine learning reads, doing it correctly. If it didn't read correctly, we would have to correct it, then the bot will learn from that, "Okay, this is actually the better way," so it can do better next time.
They are still new in the market. Or, at least, they are still a small player. They require a lot of improvement in terms of learning material as well as the community developers. If you compare Jiffy.ai to an established solution, like UiPath, you can go to YouTube and find a lot of learning material posted by UiPath, partners, and other people in the community. However, for Jiffy.ai, you won't find that available in the market. Because of this it is very hard for us to find talent in the market. Most of the developers in the market are used to the bigger players. For Jiffy.ai, if you search a resume because you are trying to find someone who has used Jiffy.ai, you won't be able to find it. So, when we onboard a new person, we want them to learn this new system, but it is a bit hard for them to pick up because there are no external learning materials on the Internet.
For training, they provide the foundation and advanced training. If you have other issues, they have a support portal, which shows a brief summary of the features. It's not very extensive, like Google Cloud Platform. Sometimes there are things that may not be available in the portal. While other products will also not have available the information in their portal, other people know it. So, you don't have in the community discussions about solutions to a problem that would not be available in the portal.
We started this project last year in May.
In terms of the portal’s stability, the system is quite stable. We almost never have downtime, and if so, it is very minimal. However, in terms of bot stability, it depends on the server. The bot sometimes gets stuck, then you have to restart the bot, which is something for them to improve.
I do not see any issues in terms of scalability. We can automate a process for a certain department and that process can be very similar to a process of another department. We might need to just change it a little, so we can use the existing solution that we have created. For example, if we create a reconciliation, then the same engine can be used for any big reconciliation tasks in other departments not related to finance. It could be done for engineering, operations, etc. It is very scalable in terms of reusing the existing solution.
They are still quite a small player. Because of that, they can focus on the customer a lot more. If I am comparing them to a bigger player or other players that we have worked with in the past as well, they are a lot more responsive, passionate, and focused on us. They help the customer.
We can create almost any type of solution in a very inexpensive way. In the past, we bought software to do certain processes. However, with Jiffy.ai, we can build the same software at a fraction of the cost. We no longer had to buy this other vendor's software anymore, which we licensed every year. With Jiffy.ai, we just have to pay the setup costs in the beginning and have them do it for us. We wouldn't have to pay them if we are doing it by ourselves. If you just use their service and do the setup ourselves, then we don't have to pay for the service, we would just need to pay for the service to use the Jiffy.ai platform to build our software. So, in this example, we are actually saving 97 percent of the costs.
The deployment process is quite fast. Because they are small, they could focus on us. With the development, there are not a lot of processes to do it. We just have to set up the server. We can use their cloud, as cloud hosting or hosted in our on-premises. Even if it is hosted on-premises, the setup is quite fast. Training our staff was also quite fast. I didn't have any issues. I was quite happy with the setup.
The initial setup could take about a month or less, but we also had the incremental setup for our sister company. So, we have multiple entities in our company. The first time that we set up, we set up from scratch so there were a lot of other things that we needed to set up, but setting up another tenant for our sister company took a few days.
The reduction of work on a manually basis by project is between 50 to 90 percent. There are some processes where we almost automate the whole thing, and we just need manual handling by a person in certain rare situations. In that case, the reduction could be 90 to 99 percent. However, for certain processes, we can only automate 30 to 50 percent because the rest of the process still needs to be done by a human because of regulatory purposes, etc. So, it's a huge range: 30 percent to 99 percent.
The pricing is quite competitive. As a small player in the market, they are quite aggressive in their pricing. With the features that they offer, it is quite worth the value.
Before we chose Jiffy.ai, we looked into other solutions, especially bigger, more established solution providers, like UiPath, Blue Prism, and Automation Anywhere. In terms of simplicity of usage, Jiffy.ai is easier to use since they are on a webpage. We put a portal on it and everything is available there. The UI is a bit more user-friendly and intuitive.
In terms of trying to do end-to-end process automation and how easy it is to do it, these are big pros and cons when compared to UiPath. In some ways, they are easier, and in some ways, they are not. I like with Jiffy.ai that we can use Python, but with UiPath, we can't use Python and need to use .NET. I'm unsure if they have enabled Python now. We also have a lot more flexibility with Jiffy.ai, e.g., we can connect to Google or any kind of system without having to do integration. We can just go from the front-end and record it. UiPath has this as well. You need to install Orchestrator on your PC. Then, you can install the design anywhere, because it is web-based, which is an advantage.
In other solutions, you have to install and set it up. If I have a new developer come in, then I have to install the system on their laptop before they are able to do their work. With Jiffy.ai, you can do it anywhere, on any laptop, as long as the laptop has access to the webpage. You just need access to the webpage, then you are able to do it. We control it from the portal as well. So, if I want to shut down or restart the bot, then I just have to go to the portal. I don't have to go to somewhere else, log into the server, or remote desktop to several laptops to do it. Everything is centralized on one laptop in one portal: the user access, the bot management, the task management, and the user interface for the human to manually handle certain stuff. Everything is on one page. This is an advantage over other solutions.
You have to be open to trying new things. There are certain things that if you are already used to other bigger players in the market, then there are things that you like and things that you don't like. However, even the things that you don't like, it is mostly because you are already used to the way the service player is doing it. Therefore, if someone is doing it differently, it could be actually better, though it may not feel like it. I think you will find it exceeds your expectations.
Even with using humans, we have multiple redundancies to ensure there are no errors. The end results are not a lot of errors, though using the bot reduces the redundancy in having people check each other's work.
We are still reducing the full-time employees doing the work, but not up to 100 percent. We still need to maintain certain people for handling tasks that can't be handled by the bot, like manual exception and manual handling. Therefore, we cannot 100 percent automate everything. There are certain scenarios that require human judgment, preventing us from using the bot to do them.
I would rate this solution as an eight (out of 10).
Our use cases are account receivables and account payable. In insurance, our use cases are for vetting beneficiaries, upgrading client portfolios, and updating customer's policies.
The entire tool is valuable because it is an enterprise tool. It is on par with other tools like Automation Anywhere or UiPath with the OCR/ICR facilities, analytics, and the entire package for enterprise-level security. It has the highest level of security as compared to any other tool.
There are a lot of things coming up, such as Discovery Bot and Process Discovery. A lot of other aspects are also maturing. We have definitely started using it for our clients, and it is maturing as a solution, but it is all about how you integrate the enterprise with all the automation projects, such as your chatbot, Conversational AI, and robotics. How they are integrated and talk to each other creates a very good business case with all three aspects. The next level should be about integrating it with other automation tools as well. It can have integration with other tools or automation projects, such as your chatbot, Conversational AI, and robotics.
I am in robotics for the last seven to eight years, and I have been using Blue Prism for about three to four years.
Stability-wise, it is a good tool.
It is definitely scalable. The whole market of RPA is definitely scalable, but it again depends on your feasibility and complexity when you study a particular environment and process. It also depends on whether you want to scale in the whole organization or different departments or you want to scale up into different areas. All RPA solutions are on par in terms of scalability. There is no difference between them.
I don't have any direct experience with them. My solution architect used to handle that. I haven't seen many technical issues because if you are going to deploy the solution and if you've studied enough about the organization and the architecture, then something major is not going to come up. Anything minor, such as securities, passwords, or anything else, can be easily managed.
It is completely run by the solution architects, which is the support team from the RPA side. All technical issues definitely involve the IT team, which is your internal architecture support team and the application support team. You need the support team from the architecture and the IT perspective to manage the technical follow-ups.
I have also used UiPath and Automation Anywhere. All these three solutions stand out because they are at the enterprise level. As compared to UiPath and Automation Anywhere, to use Blue Prism, you need developers who have hardcore development experience. It requires quite a bit on the development side. In Blue Prism, you can also code separately and write a script, which adds more value to it.
Blue Prism came too late into the market with its analytics and process discovery features, whereas Automation Anywhere and UiPath were the first ones in the market. Blue Prism is catching up, and it is in the Gartner quadrant, Forrester, etc. It is not lagging far behind.
In Europe, Blue Prism has captured a lot of markets. In the US and Asia, you will see Automation Anywhere and UiPath in the front race. Microsoft, WorkFusion, and Pega are also catching up now.
It is not that complex. It is about how you study an organization and how an organization's architecture runs through. If it is a big organization or an enterprise, then you have to have solution architects from the customer side and also from our side. Solution architects will go and study the customer's architecture. Based on that, we can select which tools are going to be used and how complex it is going to be. It is very much dependent on how the architecture of an organization is because you are going to place the automation tool into that particular organization. Therefore, the initial feasibility and study play a major role in defining the complexity of your design and the entire format or automation.
Initially, the deployment used to take quite long. Now, it is not client-based; it is web-based, and the installation process has been reduced. You just download, and there is no starting a client and all that kind of stuff. It is much easier now than it was before.
In terms of the staff required for the deployment and maintenance of Blue Prism, it depends on what kind of process you're managing. It is not about the tools; it is about the processes. You need to know:
Generally, one person can easily support around five processes if they fall into the simple category. If the processes fall into the complex category, then you need at least two people managing five processes. By complex, I mean when you have applications that are lengthy and the number of steps of the process are more than 500 or so, and you have to monitor the bots very closely. When the bot or the process breaks, the support team needs to take over and act accordingly.
The roles and responsibilities and the kind of people needed for maintaining the solution vary based on whether you have agile project management or a lot of projects going on. Typically, you will need a solution architect. You would require an analyst only in the first two or three months or whatever is the period for taking care of the process you want to deploy. After that, you don't require the analysts because it only needs to be overseen from the business side, which will begin with SMEs and the production support team.
Any changes or optimization after 90 days, six months, or a year, due to multiple factors such as legislation changes or anything else, have to be done in the process that is robotized. At this stage, the SMEs and the support team play a very vital role. There should definitely be a very good support function because a lot of follow-ups happen in the process and the production in robotics. To manage them, there should be a very good ticketing system in place. The Agile methodology works perfectly fine, and it adds great value to run your process effectively and having an efficient process, but you definitely need the solution architect, application owner, project management team, and the COE team to manage the entire workflow, work items, or backlog items coming into the support function.
It is a bit higher in cost as compared to Automation Anywhere and UiPath. The rate also differs from client to client. Margins are also important when it comes to costing and licensing. There are some additional costs involved besides the standard licensing costs. You have the development team cost, which includes the project manager, development team, analyst, and testers. You also need a team manager. You also have the tools cost, architecture cost, platform cost, and the licensing cost of each bot.
You should suggest a tool only after you study the architecture of an enterprise. Every tool has its own features, upside, and downside. It is not about necessarily going for Blue Prism, Automation Anywhere, or UiPath. For implementing a solution, you definitely need to look in the market to find out what suits you. You can then go for it.
Blue Prism, Automation Anywhere, or UiPath are on par. There is not much difference in those tools at an enterprise level. The early development cost and the cost of the platform differ in these three tools. There are some clients who say that "We want only Blue Prism. We don't want to look at anything else." In such a scenario, you can definitely go for Blue Prism because it is on par with other competitors.
The biggest lesson that we have learned from using Blue Prism is that it is important to choose the right processes and the right complexity of the processes. You can't choose highly complex processes where you have around 800,000 steps or very volatile processes where the team is involved in the application layer or at the process level very frequently. These kinds of things could be avoided.
I would rate Blue Prism an eight out of ten because it is a very old tool. It has been around in the market for quite a while, and they have their own learnings. It is a complete package at an enterprise level, where you can have analytics and attended and unattended automation. You can run your scripts, and at an enterprise level, even security aspects are very strong as compared to what is generally required by a client. There is room for improvement. All the new features that are coming up are not being used by many clients, and a lot of learning has to happen.
We started out with accounts payable, and now, we're starting to do more vertical revenue cycle management in healthcare. We're starting to use it for other things.
We're on version 11, but we're moving to 2019 or 360. We're in the process of migrating right now.
We were able to replace a lot of the manual and data entry workload that our accounts payable clerks were doing. We had 18 accounts payable clerks, most of them are still there with us, and the work that was done before by this original group can now be done by four people.
The ease of use in getting started is probably the big thing. They had a lot of references that we were able to check. It is a well-known player, and being able to get up and running quickly was the big thing.
Migration is probably our biggest challenge. When we were trying to do the migration to the new version, it was a little bit painful. We didn't have that many bots, and I can't imagine the level of effort that some of the bigger customers have to put in for that. The product is stable, but moving from one release to the other was the issue.
We also had difficulty with some of the documents that we were trying to automate. IQ Bot or intelligent document processing doesn't have all the features and functions that we were originally told it had. They need to improve that. It had some limitations, and we've had to add other products to the mix just because they weren't able to deliver some of the things that we were told that they could deliver upfront.
They've been talking about task mining for a while. They don't have a good tool out there to evaluate the current processes and come up with a plan. It is a trial and error process where you have to sit down and go through what different people are doing, for how much time they're doing it, etc. There isn't a good systematic way of capturing that information. There are other products such as Kryon, and there is a new product called Soroco that we're looking at, that would let us evaluate the task that could be automated. So, it is not really process automation; it is task automation. You don't really see end to end when you're doing these projects. You don't just decide to automate the whole process. You select the tasks that you are going to automate, but you don't really know the effect that particular automation is going to have on another task. You don't have the big picture. It would be very helpful if both UiPath and Automation Anywhere provide a center of excellence that you could run on your systems so that the people who are running things come back and say that:
All these are manual today. You're looking at what other companies are doing and hoping that you're going to get an ROI, but you don't really know until you start the project, and by then, it is too late. You've already spent the money on the software, the bot, the integration, the services, etc. At the end of the day, you're thinking if you would get the ROI. You have to measure it to see if you're going to get it after you've already spent the money. It would be really nice to have something that you could run upfront to know about the automation tasks that are costing you money today and where you should focus your efforts on automating.
I have been using this solution for about two years.
It is pretty stable, but moving to the new release has been a major pain.
Its scalability is great. It is for sure built for enterprises.
We have six to eight people who are doing validation now and are actually using the product for validation. They are accounts payable clerks and healthcare revenue cycle management folks.
It is being used extensively in the finance back office, and the idea is to bring it more to the front office for customer onboarding and things of that nature. We haven't done a lot of that, but that's in the plans. We are trying to figure out the next processes to automate.
It is good.
We didn't use any solution previously. We did add UiPath to another area of the business, so we did bring on another vendor just to see what the differences were and how easy it was to use compared to the other one. We haven't really said we were going down one path as a company. We didn't want to put all eggs in one basket, so we decided to do one project with Automation Anywhere and one project with UiPath and compare the two.
UiPath has a little bit better document management. They have some process mining that we've started to use. Pricing is roughly about the same. There is not too much of a difference. I haven't seen too much significant difference between the two products.
It was pretty straightforward. We originally thought we could do it with internal resources, but we had to bring a third party in to do it. So, it is straightforward if you have experience and training. Our tech team can do it now.
We started out with a simple invoicing, and the bulk of it took about three weeks or so. Testing everything probably took closer to six weeks. We finally got it going in two months.
When we first started, we thought we could have more of our team doing it, but we had to bring a third party in to do the bot building and all that. It was a reseller, and they had technical people. Our experience with them was good. They were a little expensive, but it was good.
For its deployment and maintenance, we have about three people. We have created a small center of excellence team with three, or sometimes four, people. We have a business analyst. We have two developers, and we have somebody from finance on that team who is putting a lot of hours into that piece. We're truly trying to figure out the next processes to automate.
For accounts payable, we saw a return in about five months from the time we started. There was a significant reduction in the number of hours that invoicing was taking. We went from 18 people to 4 people. We didn't let all those people go, but we did let a few people go, or we moved them into different job functions.
We're paying a monthly subscription fee for the bot and for services. There are no additional costs beyond the standard licensing fee.
I would advise looking at other companies to know what they're doing. I would also advise putting a complete plan in place so that all bot management needs are considered upfront. It is helpful to put a roadmap in place and have a center of excellence or something like that to make sure that the processes that you're going to implement have an ROI. You can validate the effort upfront by using process mining or other tools and evaluate what the effort is now and what the savings are going to be upfront.
We did a couple of projects that we thought were going to have significant ROI, but they didn't. It was more of an internal process that we had to fix. It wasn't so much about automation; it was about the way we were doing business. We weren't following processes, procedures, and things like that, and that was what was causing the issue. We had automated a bad process, so it didn't have the return that we thought it was going to have. We had to do some procedures. We had to change some things internally.
I would rate it a seven out of 10. It's a good product. It does what it's supposed to do.
We are using WorkFusion as our enterprise RPA solution at this time to help us deploy some automation. It is a hybrid-based installation. Eventually, we are going to try to move everything to the cloud. Some of our customers are dealing with transactions, trader solutions, governance compliance needs, and other special cases so it is not totally possible to go totally on the cloud at this time. There are also clients who deal with things like a KYC (Know Your Customer) type solution, and then a few operational needs like ATM reconciliation and financial revenue reconciliation. The regulations sometimes preclude certain solutions in certain configurations.
It helps us to provide some of the bot solutions we need to work with our customers.
I suppose that the most useful feature in WorkFusion has been the desktop solution — also known as a desktop option. It is a type of RDA (Robotic Desktop Automation) express option because it allows us to do very quick developments outside of the normal BI (Business Intelligence) process. Even though the bigger enterprise is obviously more robust, there are a lot of small solutions that can solve pain points in our business at a particular moment that do not require more rigorous development.
Obviously, the WorkFusion Enterprise product is very technical. You have got to be Java proficient and otherwise technically oriented. I guess what could be an improvement in the product is moving towards more "codeless" coding. That would be using things like a drag-and-drop interface to build solutions with premade components. These components would have set functions to simplify using the coding portion of the product for the business user. Instead of keeping the product in use with only the more technically inclined users, they might create a way for the business user to assemble what they need and enhance development opportunities.
I think a move towards that sort of codeless coding would be a great step in creating more utility for more end users. Maybe API calls or other creative components could be worked in. The express version does not do API calls and the Enterprise version does not do codeless coding. It would be nice to have a solution somewhere in the middle. WorkFusion has got the very easy, light version covered and the very technical, heavy one covered. There seems to me to be a gray area or gap in the middle where a whole set of potential users is not addressed.
I think our organization has been using WorkFusion for three or maybe four years overall. With my group in the Africa regions, we have been using it for about two years.
I do not think we have ever had issues with stability. It seems to be very good from my personal experience. It is more likely that something in the solution will be affected by the environment changing than it just breaking down. The question becomes can an RPA solution adapt to changing architecture through various upgrades and version changes and remain compatible with the environment.
The stability of the product itself is something we have not had issues with.
I would say there are probably just less than 100 users currently working with WorkFusion at our company. I am not sure what the total number is, but probably less than 100. Within the African group, we have probably got about 15 to 20 total users.
Most of the people using the product are using it on a daily basis. The processes created as bots are obviously running in real-time all the time. The developers are either busy with deployments or they get involved from an analysis and design perspective. But working directly with the product consumes a high percentage of the users' time.
Our scaling is simply replication across countries and geography. There are always new projects and configurations that need to take place to augment the system, but it is pretty easy to scale usage of completed bots.
I do not ever have the need to contact the WorkFusion tech support directly. We have got a Center of Excellence that supports us from a group perspective. We deal with them and they deal with the vendor if anything needs to be resolved.
This solution is actually the first RPA I have used. Maybe it is not so surprising considering the technology is not very old.
I joined the team after all of the internal architectural decisions, choices, and implementations were completed. Because of that, I can not really comment on the evaluation process. I have just been making use of the system that was in place after its adoption, and I can not really complain.
I was not involved in the initial installation as it happened before I arrived. I can only say that I have not heard anything about the issues that may have occurred.
It does require maintenance and there is ongoing support from a technical training standpoint. Then the bots themselves require maintenance and updates. That is, if there is anything that changes in the environment or any process changes, the bots may need to be reconfigured — or even replaced — to work with the changes.
WorkFusion is cheaper than quite a few of the potential solutions, but we have also heard some complaints that it is a more expensive solution than others. It is certainly not the cheapest solution. I think Help Automate came in as quite a bit less expensive. Obviously, we have to have an enterprise solution with a company of our size and there is an opportunity to negotiate to potentially work out a volume discount. That would make the cost less significant in the choice of what we continue to use.
As far as I know, all other services are included in the license as a single point of pay without any additional fees.
While we have got WorkFusion as a solution at the moment, we continue going through due diligence. We actively check and evaluate the alternatives that are available. We consider it an ongoing or proactive review of our current toolkit. We currently use mostly WorkFusion, but we also use Python for some of the other automation. We are looking at other important products like UiPath, Blue Prism, Automation Anywhere, and Help Automate. Those are the tools that we are pulling in to use for our comparisons. One of them may solve potential pain points the current solutions do not.
Overall, I would recommend this solution to other users. I have got nothing against UiPath or Blue Prism or any of those other products, and I think there are other options like Python people can make use of. But from my experience with this product, I certainly recommend it.
On a scale from one to ten where one is the worst and ten is the best, I would rate WorkFusion about an eight. Between a seven and an eight but on the high end of that range.
The reason why we are using this product is that we like to use it where we have automation projects specifically for Microsoft products. We can automate to improve productivity and for those applications and simple tasks, it is easy to use.
For example, suppose I get my email with Outlook. There are certain times I will get specific Excel files from a pre-determined output which I have to always place into a particular SharePoint folder. From there, some other automation gets triggered and the file is processed in a certain way. Those are the sort of things we can automate with Power Automate. It is very good at working with those simple Microsoft-product-related processes.
We use it wherever we have workflow processes in which Microsoft products are interacting. Before using this solution, people would get those emails and the recipient had to download the file and then manually put it into SharePoint. Now, as soon as it comes into the inbox, Power Automate gets triggered and it automatically copies the file to the correct SharePoint. There is no reason that a repetitive task of this sort needs to be done manually.
It offers a different option than using UiPath which is much more complicated and more expensive for simple tasks that Power Automate can do more easily.
It is very hard to say what the most valuable features are in Power Automate because we are still exploring the product and utility. I like the simplicity of how we can create those automated activities quickly. For now, the most valuable feature is that it is very easy to use.
There is definitely a lot of enhancement that Microsoft can incorporate into Power Automate. For example, we have quite a lot of .NET applications that we created. These are custom applications that we created using something like VB.NET or C#.NET. These are obviously applications that are not published by Microsoft. I would like it if Microsoft could enhance the capabilities of Power Automate to allow users to connect to other tools and applications in some way. That will help us create better processes without making them more complicated or having to use another automation tool. Right now, we have to use UiPath to help us make processes such as the one described. I have not seen any way that Power Automate can do that type of integration. So if we could get better integration with non-Microsoft solutions as a feature for Power Automate, that will be very useful.
We have been using Microsoft Power Automate (formerly Flows) for the last three months.
We have not created anything complex, so we have not faced any issues in the form of glitches or any bugs to this point. When we start doing more sophisticated workflows, that may end up being a different story.
I have not really had much of an opportunity to test the scalability of the solution yet. If we find a particular workflow that requires a change or something, it is easy to drop that version and recreate something new from scratch. It does not take much time. Scaling the number of processes up or down at this point does not seem to be an issue.
The number of users in our company right now remains pretty small. I think there are only around 15 to 20 of us are actually exploring the capabilities. Eventually, that group should be much larger.
We have not had any reason to work with the technical support team at this point. One of my colleagues did drop them a note asking if there is a way we can use Power Automate to connect to any of the custom tools that we created. I do not believe that we have got an answer to that question yet, so it is taking some time.
The initial setup was quite good and went smoothly. It was not complex at all. It is good that it was relatively easy because we understood that it would mostly be used for easy processes to do some small tasks. We went that way and are using the tool only for working with simple automation processes. We did spend some time trying to automate more complex processes, but as the processes became more complex the tool became more complex to use. It is much easier to use it to do non-complex things. The setup for the processes themselves is fairly easy to do.
This solution can save money when used for simple tasks specifically using only Microsoft products.
We are currently working on evaluations of various products. The thing is, we have just started to embark on our journey into RPA (Robotic Process Automation) and we have brought in UiPath to act in that capacity. We are very much, at a nascent stage of the discovery of what we can do and what the product is capable of. We are identifying processes that can be automated and we are planning to work mostly with UiPath on those solutions. We have already engaged in a contract with UiPath for use of their product at this point in time.
Most of our work is going towards UiPath currently but we also have this Microsoft Enterprise licensing. There seems to be no reason we should not use that as well if there are ways it can provide an advantage. We are also exploring if the enhancements we would need to tie in other applications and processes to Power Automate are something that we could do internally. At this time we are working with a combination of solutions that falls somewhere between our existing processes and new capabilities with automation tools.
I have a few comments and advice for people considering the addition of RPA in their workflows. I would suggest that they do as much streamlining of their processes as possible. If they can get smaller things up and running by creating the process with a simple tool it may help their efficiency as well as their bottom line. When you go for big tools like UiPath and all the other robust RPA solutions, the cost of creating those smaller processes will be higher than they need to be. If people have a Microsoft Enterprise license, they could actually use the Power Automate tool to make their processes much more lean and efficient. Doing the same thing by employing any of the RPA-related solutions and tools might be a lot more effort.
On a scale from one to ten where one is the worst and ten is the best, I would rate Power Automate, overall as a product as a six-of-ten at this point. It has got a lot of room for improvement.
