My Singtel Journey

Project 1 - Files Download

My first interaction with singtel came before my deployment. I was called on for a quick RPA fix for a client. As my boss wanted me to build up some experience he offered me to fix it. The requirements were basically to create a bot that go in to a website and download some stuff every 30 mins. Sounds simple enough? Oh, the horrors the follows.

I had three days to build the bot. I completed the workflow in one. I was pretty proud of myself. Looking back, it wasn't really anything to be proud of. It was that simple. What came next was migration to production. When I tried to migrate my work, I realized that my work was pretty much incompatible with theirs. They were using a different version of UiPath, Ver 18.4.4, mine was ver 19. I had to redo everything.

Next, I had assumed that there is a location within the computer that the client wanted me to download to so I just set it as configurable. Turns out that he wanted it up on a sharepoint. Spent another few hours trying to get through the front-end of sharepoint when I realized that there was a package for UiPath. Sigh

By the third day, I was bumbling around and hacking around in a frantic mess. Somehow I was able to push the product live at the end of the day and managed to help out our dear client. Finally

What I Learnt:

The most important thing about coding is the requirements. Always be 100% clear on what they are.

Project 2 - Market Survey

My first project after being deployed into singtel. This is probably be one of my most challenging project to date. Basically I had to take in payroll information for singtel's employees and convert them into a readable format submitted to vendors. That's vendors with an s. 4 vendor. And each of them had their own format. Feels kinda unfair that this is only labelled as one project.

What was the most difficult part of the project was matching employee's job title. You see, the job's title are not the same. But there is no mapping provided. What determines a job grade is a whole lot of factors. I then create said factors and use them to create my own map. From there, I can filter out a whole lot of job titles provided by the vendors.

Still, a large portion remains. I had the user's singtel's job title. And a bunch of possible job titles from the vendors. And what usually happens here is a very human process. For example, Sales Director = Procurement Director. I need a thesaurus.

So, I created one, a custom one. Furthermore, there had to be points associated with it. Some words are meaningless in our field. Noise and vibration engineer? Hmmmmm. Anyhow, the thesaurus are to be maintained by the user so they can keep adding on to it as new job titles pops up.

What I Learnt:

Hash Tables/Dictionaries are your friends.

Project 3 - Letter of Appointment

Yet another project where I had to do multiple in one. How is it considered one project when the entire workflow is different? I'm basically dealing with two types of employees that get hired into singtel. The first are regular employees. They had to have a custom letter created for them so the fastest order of growth is linear. On the other hand, intern do not need custom letters so using select statements the process can be done very fast.

This two process had clear and well defined requirements so the project delivery was very smooth. However, the front end part of the process is dependent on the websites used, which was kind of slow. So that lengthen the process runtime. Still much better than doing it myself! My client had said. Can't really argue with that.

What I Learnt:

Orders of growth are just a rough gauge. In real projects your linear workflows may take longer than a quadratic one.

Side Project - Build a bot workshop

This project was done upon request from another department that wanted to raise awareness on the process of RPA. I was there as a facilitator. Meaning I helped the attendees out as they attempt to build their own bot. This workshop wasn't to teach them how to create their own bot. Rather, it is to let them understand what process can be automated and what cannot.

At the end of the day, they gained a deeper appreciation for us developers and it is also easier to communicate on the workings of RPA for both side. It was a successful workshop and a great day.