Blog

This week I’d like to admit something to you. When I called Rafał to discuss the issues related to the Framework, I realised that working with the entire XELTO DIGITAL team is a pure pleasure. Each person in our team is responsible for specific process automations, but if anyone of us is facing an issue that they can’t figure out they are not left on their own with the problem. Thanks to this support, joint discussions and “brainstorming”, a model for building robots has just been developed. But before we talk about all of this with Rafał, I have to, at this point, thank my colleagues for cooperation. With the Expert’s eye: UiPath promotes the creation of solutions based on the ‘Robotic Enterprise Framework’, which ensures the basic implementation of the key concepts which support the creation of automation.  Together with the XELTO DIGITAL team, we have gone one step further and developed an expanded version of the framework, which forms the basis of the robots we build. What does this give us?   1.Standardisation For each customer all processes are built in exactly the same way. This has allowed us to implement a number of common mechanisms at the design stage. When opening a new project, the developer no longer has to worry about logging, main error handling or preparing the environment. For example: when using the TypeIntoElement procedure, the developer will log with a single block if an item exists, write the value for it using the method of their choice, check that the value entered is correct, and if something does not work, they can repeat it X times. In addition, both logs and error messages have a uniform format and provide us with key information. 2. Security With built-in mechanisms, each process can make the basic preparation of a machine for operation and leave the environment ready for the next robot. In addition, whatever happens, the robot is able to gracefully close all open applications and leave the workstation in the same condition as it found it. If the robot works on a Windows server, it knows that it should shut down processes for a specific user session only, allowing multiple robots to work safely at the same time. 3. Accelerated production It takes about 30 minutes to prepare a model for a new project. During this time, the developer receives a package of end-to-end solutions for which it would take at least a few days to design, build and test if it was done on a one-off basis. In turn, the use of reusable components allows for the quick construction of process actions. I’m writing here about both the universal procedures in the framework and those developed for specific applications which are available in the auxiliary libraries we have built. For example, the already mentioned TypeIntoElement and ClickElement will run on each web application, while the NavigateFastPathJDE is a procedure built exclusively for handling the fast track in JDE. 4.Better Technical Support SLAs  The standardisation of the robot creation process improves the diagnostic time if errors occur in the process operation. There are two reasons for this: first, specific errors can only occur in specific locations. If the ODBC connection does not work, we know right away that the problem should be looked for in the ‘get transactions data’ area. As a result, the time required to find the problem area is significantly reduced. Second, we have introduced uniform error codes for all robots and divided them into those for which the business is responsible and those that appear as a result of the applications used. If, when monitoring the work of robots, we see a message, such as B0001, it is immediately clear to us that the robot failed to log into the application because the password had expired. In summary, the implementation of our own robot building model means that the new processes are built more quickly and safely, easily fitting into any existing robot infrastructure at any customer’s site. Author: Rafał Korporowicz – Senior RPA Developer Foto: iStock

In 1983, the Times magazine cover depicted a robot carting a factory off on a wheelbarrow and announced the article entitled: The new economy. The article was devoted to future predictions in the time of a recession and bankruptcies in heavy industry, prophesying a reduction in blue-collar jobs. It was a time when the industry of new technologies, as exotic as microelectronics, laser, genetic engineering, was emerging; completely new areas of development were coming into existence, as in the case of Apple, which was just then transforming from a garage company into a powerful corporation. Concerns were rising about the development of automation and the possibility of replacing entire sectors of workplaces, thus far controlled by man, with robots or automatic machines. But after all, man has been afraid of automation since the launch of the first machines. We have heard of the destruction of machinery in factories in the early 19th century; it was a well-organised movement of the so-called Luddites who were protesting against the changes in the way of their life and the threats posed by the invention and application of weaving machines. Night attacks on the weaving plants, the destruction of machinery or the intimidation of people did not reverse the industrialisation process, similarly as the ban on using pneumatic paint sprayers by factory workers imposed by the American trade unions almost a century later. Nevertheless, it clearly showed that fear of the new has and will always accompany man, irrespective of the times they live in. However, figures say that the mechanisation of production led to a sharp increase rather than a decrease in the number of jobs. For example, in the USA, 140 thousand people worked in the motor vehicle industry in 1910, while in 1920, as mechanisation was progressing, the number of jobs increased up to 250 thousand, and in 1930 there were as many as 380 thousand people working in this sector. Following the publication of the article “The Future of Employment: How susceptible are jobs to computerisation?” by Carl Frey and Michael Osborn in 2013, the app WILL ROBOTS TAKE MY JOB? was even created and it has been working up until today to tell you how likely it is that your position will be replaced by robots. Are you a computer system analyst? – today, the likelihood that your position will be replaced by a robot is extremely low, amounting to 0.7%. At the same time, the purchasing manager position, meaning the tasks of an employee in the procurement department of a large company, already has a 98% risk, with a further 59% increase in the next two decades. But the risk of an analyst being replaced will increase by 32% over the next 20 years The article predicted that the low risk of job computerisation concerns only one in three workers, mainly those employed in education, health care, artists, managers at different levels and, of course, IT professionals. But will this perspective look the same in a few years’ time? As we have mentioned, fear of automation is not new. Today, as a result of automation, certain groups of employees are being made redundant, but, at the same time, new jobs are being created (often paid better than the ones that were lost), and usually, with the exception of the difficult transition period, the situation is improving. Let’s consider machine learning and robotics, which find ways of doing the same things better, faster and cheaper and for which people with specific competencies were employed for decades. In the event of such a specific replacement, employees are moved to other roles. And again, as in the case of the industrial revolution, it is rather unlikely that the transition period will be painless. Time will be needed for people to retrain and for managers to reinvent roles for the freed workforce. And they have much less time than they had a century ago. Changes are taking place faster than ever and have a much wider reach. In conclusion, let’s return to the Time’s article. A quote from 1950 was cited there. It is the opinion of John Diebold, a management consultant from New York: “At various times, usually at the depth of a recession, people have said it was going to be horrible from here on because of automation. But a couple of years later, it’s all forgotten. Certain types of jobs die, and others grow. That is the sign of a healthy economy”. There’s nothing to add, despite 71 years… Source: Will Robots Take My Job, Strach przed automatyzacją (Fear of Automation), https://en.wikipedia.org/wiki/Luddite, (TIME) The new economy Author: Monika Stawicka – Business Analyst

To standardise or to automate – that is the question. Not only did the great classics like Shakespeare ask themselves and the world important questions. Sometimes I like to sit on our company balcony and think about the different aspects of automation and other things. As it turns out, our small balcony is loved by all XELTO DIGITAL employees. Watching the sunset, we started a rather interesting polemic with Monika: With the Expert’s eye: Each business is constantly changing. The way in which a company deals with changes when labour costs are increasing, when customer demands are growing, when fears arise concerning the effectiveness of the existing solutions, or when competing with competitors. Being aware that changes are expensive, we look for the areas where the process of changing will allow the goal to be achieved in as short a time as possible and at the lowest possible cost. What to start with then? Certainly, with naming the points that slow down the processes, the elements that generate most errors or consume large amounts of time bringing poor results across the company. In every business, processes can be found that are obsolete, involve old technology and are largely based on, unfortunately, human fallibility. This is particularly evident in large companies, which have many branches and where a process defined at a specific time and place (which has, actually, been very useful for a long time) begins to act up. It slowly becomes inconsistent or is conducted differently depending on the conditions under which it is triggered. Operating conditions often play a role in unintended process modifications and cause its original definition to disappear below the layers of interpretations and exceptions. (These conditions may include business units located in different countries, with different working cultures or different customs.) Any advice? The first and, for some time, the only solution was to look at every event in the same way whenever it appeared or whenever a specific type of work occurred and make an attempt to standardise it. Standardisation meant that all known steps were unified until consistent processes were achieved. Needless to say, the operation of recognising and evaluating various tasks and events itself has always been time consuming, and it entails measurable costs. If we now add the time required for another effort, i.e. automation, the moment when the expected changes are achieved is postponed. Therefore, the question has to be raised: what is the real purpose of this operation? Do we want to have standardised processes (ready to be automated) that run uniformly across all areas of the company, or it is about saving labour costs and unlocking the potential of people? If we think of standardisation itself, we can forget about savings. So, rather than comprehensive standardisation prior to automation, let’s focus on standardisation THROUGH automation. The selection and identification of processes that need to be changed is a prerequisite for this. Let’s replace the time we would spend on, to say colloquially, straightening crippled processes with putting effort put into analysing the areas where process automation will be the best solution. The most important goal of automation should always be the willingness to relieve your employees of the burden of laborious and monotonous tasks to finally enable them to develop themselves. There is an interesting observation: from the employee perspective, standardisation does not change much, unlike automation. Given the expectations they have with regard to both processes, the employees are much more actively interested in the introduction of automation, because there is the opportunity to turn the laborious tasks over to a robot at the end of this process. By getting rid of repetitive and frustrating activities, they simply get back to commitment, often lost a long time ago. To recapitulate, without sacrificing it, standardisation can be modelled to be part of automation, not an end in itself. And what is equally important, attention should be focused on the potential of employees. According to observations, the employee’s potential increases in proportion to the delegation of tasks to robots. Autor: Monika Stawicka – Bussines Analyst Source: Should You Automate Your Processes “As-Is” or Standardize First?

I’m smart, I’m courteous – I’m already well prepared to automate a number of business processes in a cultural way for you. As you well know,, companies use a lot of applications, run on multi-year systems, and process a huge amounts of data that are growing daily. One day, we got into a discussion about ODBC with Tomek. I like our conversations very much – we both believe that the impossible is does not exist: With the expert’s eye: Working with data is an integral part of many processes – Machine Learning, Data Science, and also RPA often need to operate on complex data sets with thousands of records. In each of these cases, the correctness of data is very important and, unfortunately, the human factor is highly susceptible to errors. However, we can deal with these issues in different ways. During automation we often cope with the complex processing of large amounts of data that may stop the process at different stages, which results in less or more time loss. Therefore, it is an excellent idea to use databases of automated applications to verify supported data. Applications often have built-in input field validation capabilities, and thanks to the access we have to them, we can eliminate some process-impacting errors at an early stage. The UiPath.database.activities package is very useful for this, as it allows us to create a connection to the database through the ODBC interface, and then work with data in read and write mode. A simple example is the processes running in the ERP JD Edwards system where automation often requires the creation of new records (usually by interconnected applications). In addition, let’s stress that this system is less suited for automation, which means that some tasks can only be accelerated to a limited extent. Any time saving is valuable to us, and it is very desirable to exclude erroneous actions at an early stage. In this system, we can verify the sample input data (to be typed in one of the applications) at the very beginning by checking that the data selected by the user in the source tables storing possible values for these fields actually exist. Thanks to the above operations, we can reject erroneous tasks in a few moments, without having to catch errors when processing tasks in the JDE system, thus gaining time which is so valuable to users. It is also an additional advantage for high-priority and highly complex processes. Informing the user that his or her task contains errors before it is actually processed makes it possible to minimise the issue of urgent tasks that go beyond the specific time frame. The interface operation by a robot is probably more spectacular for users. However, everything we can do by using e.g. API to improve safety, reliability and the efficiency of a robot seems reasonable. Therefore, we recommend the cooperation of robots with databases to improve performance and thus satisfy the end-users of our processes. Autor: Tomasz Sioła – RPA Developer Foto: iStock

As you know from the first episodes, I’m quite unusual. When I started working for XELTO DIGITAL I was a normal robot. The colleagues from my team taught me more and more interesting things every day, so I could help our customers in their daily tasks. One day, She appeared … From that moment on, I decided to be not only useful, but also more courteous. A short conversation with Monika and Kamil was enough to teach me the additional rules of savoir-vivre… With the Expert’s eye: In our team, we assume that communication between a robot and our customer in the automation process is not a minor detail. For the purpose of this article, by ‘communication’ I mean all the information and messages that the processing robot sends to the operator or user of the customer by e-mails. These can be error messages, reports, or action completion information. Any information sent by a robot to a person can be either cold or, as the name suggests, automatic in reception, or sympathetic and, colloquially speaking, ‘human’. From our experience with customers, we have reached the conclusion that: the customer expects the robot to be simply courteous in communication. What does this mean for us who design robots? Let’s remember that there is a person on the other side and they are pleased to receive a message starting with: “Dear User” or “Please be advised that”. After all, if our customers treat the robot as a virtual employee or a colleague, it is understandable that this approach is translated into the language of communication, just as it is between employees who like each other. Can a robot speak any language? The robot should also be a polyglot to the extent that every user receives messages from him in their native language. It might look like a small thing, but it really works. Emails sent in English, which is invariably associated with computer language, are perceived as cold and too official. Saying this, I do not have in mind the customer’s ability to understand English. Simply, information in your native language (English customers are out of this competition) is simply more accessible. We already know that building such a communication does not require much effort. And to prove that it is worth doing so, let us give you an example of some feedback we received from one of our customers: “The robot is very polite in its messages :).” Electronic correspondence: The most common tool used by a robot for any communication is an email, which covers all the needs in this respect for most processes. We can inform the user that the robot has started or finished a process by email. We can send information about system or business errors, send a final report or a notification of any event that occurred during the process.Technically, the robot can send an email using the mail client application installed on the workstation. This method allows us to use corporate mail without needing to have, store and, in consequence, update the mailbox login data. In addition to using the client, the robot may connect to the mail server using SMTP, POP3 or IMAP, or, for a mail provided by larger vendors, it may connect via dedicated services such as GSuite, and Microsoft Exchange Server. Not just email communication: However, it should be borne in mind that although email is the basic and most popular form of communication, robots have more possibilities at their disposal. For processes whose characteristics force us to react quickly or to have more interactions with the user, it may also be useful to use instant messengers, such as MS Teams, Skype, SameTime etc., for communication. A poor substitute for communication between a robot and a person can also be a robot workflow report left in the appropriate location on the network drive, which can be a good solution if you want to avoid spam or if you do not have the right tools available. Authors: Monika Stawicka – Business Analyst, Kamil Gawlista – RPA Developer

Today, I would like to show how we can “affix a virtual stamp” in the 21st century. The origins of sealing date back to the ancient times. In ancient Greece and Rome, they were used to secure correspondence and certify the authenticity of a will. Over the centuries, the function and the method of using a stamp itself have evolved. And paraphrasing the title of one of my favourite films, ‘Diamonds are forever’, I will say that stamps are also like this. Together with Kamil, I would like to tell you about one of our ready-made tools, that is STAMPER, which helps our customers: With the Expert’s eye: Files with the PDF extension have dominated the IT world, and anyone with at least minimal contact with a PC has certainly come across them. With their advantages, PDFs have become the dominant file format with which we publish text and graphic information for a wider group of recipients. These files are also an integral part of many company and corporate processes in which documents, price lists, brochures, and many more items are published. The lack of easy editing capabilities, which is an immanent feature of PDFs, is, on the one hand, a major advantage that keeps these files in a predefined layout regardless of the application in which they are opened, but it may also be a disadvantage when, for example, you want to quickly edit or provide a legend for the PDF contents. The most popular applications to view this type of files do not offer such features at all, or offer them to a very limited extent. Fortunately, in 1996, Adobe Systems created a solution which partially responds to our needs. FDF files, which are simple text files, can be imported into the PDF to create an additional layer of easily editable objects. At XELTO DIGITAL, we went a step further and prepared a solution that combines robotics and the capabilities of the FDF format. We created a product called STAMPER. It is a tool for sealing PDFs that can work independently, or it can be inserted into a larger process during which we would like the PDFs being processed to be appropriately marked. The stamps created by STAMPER are highly flexible. In addition to their contents, we can freely edit the attributes such as document coordinates, text size, font, colour, border, background, orientation. With our solution, you can add extra information before printing an invoice, or mark the processed documents with an appropriate note. Using the STAMPER as part of the automation of office work opens up a lot of possibilities and makes it possible to clearly mark PDF files. Author: Kamil Gawlista – RPA Developer