What is our primary use case?
We are using it in production for driving our Windows application, extracting content from it, and using it for our desktop automation.
In our test environment, we are using the OCR features of the Jiffy.ai application. Essentially, we submit the images into the application, then we use the training model for the data. The actual images are being extracted and returned back to us as a document.
We automated a fairly complicated process, but it was revolving around a single application. We are not doing content switching among multiple applications. It was mainly driving a single application and extracting information out of it.
We are using version 3 in production, and we are using version 4 in our test environment.
How has it helped my organization?
We have worked on developing our workflow for driving a Windows application with individuals being either scripted or specified through the user interface.
It reduces the amount of human intervention, but you still need a human in the loop in some cases. Accuracy is not 100 percent. Someone has to go through the results. but it does reduce the amount of work that needs to be done.
The system in production completely eliminated the need for human intervention. From time to time, we need to check the user interface and results, but that is very rare. It can be done once a week, or even less frequently. Regarding the OCR, we are still at very early stages. We have evaluated the results, giving feedback and comments to the Jiffy.ai team, so there is a bit of human intervention there.
What is most valuable?
The workflow engine is definitely a very strong asset of Jiffy.ai, because it is easy to configure. It has a nice user interface. It is also scriptable. It doesn't have a steep learning curve. It is quite easy to learn, so you can become productive very quickly. Up until now, their automation tool combined with the workflow engine has been their strongest asset. It has helped us extract information out of an application which otherwise would have to be done manually. So, it gives us the opportunity to automate a lot of tasks related to extracting information, rather than delegating that to actual people. It has saved us hundreds of hours per month. It has covered the work of two or three full-time operators.
Jiffy.ai's app-based approach is suitable to automating entire complex business processes and to an approach that only automates specific tasks within a process or workflow. My impression is that the solution is so flexible that it can combine multiple applications into the workflow and interact with all of them. For example, in a Windows environment, it can launch one UI application, interact with it through the workflow, launch a process into a remote virtual machine (or interact with a remote service), fetch the result, and then feed this back into the local desktop application. My understanding is that it can deal equally well with tasks within a single process and tasks that span multiple applications in multiple environments.
It can definitely support integration with other third-parties. The combination of all these features can create very powerful applications. Our use of Jiffy.ai so far is a bit limited because we are using desktop workflows and the AI aspects of it. However, combining these can create a powerful set of features for creating more advanced applications. It can be an integral part of a bigger system. For example, you can have a front-end application that is delegating requests back into the Jiffy.ai, then Jiffy.ai will essentially act as the orchestrator for back-end services. So, it's quite powerful. The fact that it has a UI means it is accessible to non-technical people as well. So, you can get from the design phase to implementation phase very quickly.
Jiffy.ai has its own notations for specifying the theme navigation of individual nodes. That notation has the most common structures that you would expect from a programming language without some of the most complex features, like memory management or complex design. I feel it is accessible to junior developers. Now, you can be productive, even if you don't know any code despite designing the workflows. I see this being done in two ways:
- You can have someone who is non-technical design the workflow, essentially designing the control flow, specifying the input and output data, and treating this as a black box.
- You can have a junior developer who is familiar with the notation that Jiffy.ai is using for implementing individual execution nodes fill in the gaps. Of course, it needs some testing.
This is the development model that I see which is suitable for workflow entry. This means essentially that we don't need to engage expensive senior developers into managing the system. Also, it means that we can get from design to production faster. Essentially, this now provides an advantage, which means we use Jiffy.ai for more automation tasks as we become familiar with the UI and scripting notation.
What needs improvement?
Initially, in version 3, Jiffy.ai did not have support for containerization. In our environment, we are heavy users of containers and container illustrators. So, the initial deployment option was running based on individual hosts that we deployed in the cloud. That created a singularity in the way that we deployed services in our system. However, in the latest version release (4), they have full support for containerization. This has been a great improvement and one of the driving factors for switching from version 3 to version 4 very soon.
The containerization capability will make a huge difference in our deployment process, because it doesn't create exceptions in the way we would deploy services. All the rest of the system is containers, so if you now have a product from a vendor that doesn't support containerization that means you must have a different process of deploying services, then accompany it with corresponding policies, because we have policies on how systems need to be configured to be reliable, secure, etc. Also, there are the BCDR aspects of it: the disaster recovery and business continuity. So, if you're introducing a new way of deploying services, now you need to have a BCDR plan dedicated to that as well, as opposed to deploying everything using a single model of deployment (mainly containers). Therefore, this will simplify a lot of things, in terms of DevOps.
For how long have I used the solution?
We have been using Jiffy.ai in production for six to seven months, but we have been working with the company behind Jiffy.ai for about a year.
What do I think about the stability of the solution?
It is very stable. We haven't had any issues.
What do I think about the scalability of the solution?
We are using just a single node for the workflow engine. I haven't tested the scalability aspects of it.
In production, it is being used by two people. There is one person who monitors the health of the system, then a second person, who is more business-oriented, takes the results extracted from the system.
Since we are happy with this, we probably use it in other projects. The number of users might increase, but I don't see it being massively used by everyone. It is pretty specialized. I don't expect the number of users to increase sharply.
How are customer service and technical support?
They have been great. Emails have been replied to very quickly. We get on calls every time that there are issues.
Which solution did I use previously and why did I switch?
We are using a workflow engine as a library for some of the services that we have on the back-end, but nothing near Jiffy.ai.
How was the initial setup?
The installation of version 3 was a bit complex. The installation of version 4 has been improved.
Version 4 took about one hour to deploy, then the UI took about half an hour. We needed to do some configuration afterwards, so we had calls with Jiffy.ai to ensure everything was installed well, going through user creations and some demos. So, we spent another hour and a half to two hours on calls.
What about the implementation team?
I feel some minor assistance from their team is still needed to verify the correctness of the installation, but they have improved this a lot since version 3. Version 4 installation is much simpler. Still, some help from their team might be needed in some cases, especially for the workflow engine piece. The UI piece that is running Windows is very easy to install.
We first deployed the solution in our testing environment, then we ran the demos. With the help of the Jiffy.ai team, we started implementing the desktop automation workflow. They helped us get the skeleton of the workflow, then we started filling in the details. At some point after three months, we moved version 3 of this solution into production.
A single DevOps resource performed the deployment. Maintenance is required a few hours per month, depending on updates from Jiffy.ai, such as installing security patches. Overall, it takes no more than 12 hours a month of DevOps time. It is just maintenance, and that cost is quite low.
What was our ROI?
It removes the burden of having to do some tasks manually. However, we are just using it in production for a single project. It saves us a lot of time in terms of extracting that information. So far, it has made a big impact, but perhaps we need to use it in a bigger project to get a more accurate estimate of its effect on team productivity.
The solution has definitely helped to reduce errors in our organization. That is one of the driving factors. In production, we have had flawless execution for several months now, without any issues. It has helped to resolve issues because we previously had to do this work manually. For example, in some cases, the operator was forgetting to retrieve some of the information or he was placing the content into a different location, the wrong file, or giving it the wrong file name. There were these little glitches here and there.
It has saved us money from:
- The cost of the resources, who had to do this manually.
- The cost of errors.
Once someone made a mistake during the extraction of the data, then this needed to be discovered and more time was needed to be spent identifying the issue and fixing it. I believe we gained a lot in terms of both productivity and cost.
What's my experience with pricing, setup cost, and licensing?
The pricing and license make sense. They have a model based on the concurrency of the workforce, which is very suitable in our case. The savings are great on the licensing cost.
Technical support has been included so far, and we haven't needed much technical support. In case we did need some help developing new features, there might be some additional costs that we would have to incur. However, everything has been included in the licensing cost so far.
Which other solutions did I evaluate?
I believe others have looked into a Microsoft-based solution.
What other advice do I have?
The OCR aspect of it is very interesting, although we haven't fully tested it.
In the testing environment, we do use some of the AI features, which are primarily being developed by the Jiffy.ai team, not internally. We see the results, which are pretty good. We provide a number of images. The Jiffy.ai team performs the training, then we use the training model to extract information. So far, the results are very promising. We get the OCR scan results with a very high accuracy. So, we are happy with the results.
From my little experience with our OCR project, it requires some training. I haven't seen any natural language processing features, but I have seen some AI-related aspects that relate to how the image is structured and the location of individual images allows Jiffy.ai to classify words. So, it can define the meaning of a particular attribute and associate that attribute with a tag based on its location.
We like Jiffy.ai because it is stable and easy to use. We don't have any concrete projects for the future yet. We have some ideas for exposing some web services to Jiffy.ai, but nothing concrete yet. Essentially, we want Jiffy.ai to extract information from desktop applications and provide these as web services to third-parties to consume.
I would rate this solution as a nine (out of 10).
Which deployment model are you using for this solution?
If public cloud, private cloud, or hybrid cloud, which cloud provider do you use?
Which version of this solution are you currently using?