I’ve been in many different projects that range from Telecommunications, Insurance, Banks, Lawfirms, Intelligent Traffic Management, among others. I have also been involved in projects in the public sector, where we did an implementation, but I also carried out some system administration tasks.
I’m very interested in how companies solve their problems by orchestrating their whole systems and how they play with each other. It’s something that I’ve done with Pega before, as I have been at Saltech for almost 5 years. I think there’s a lot to learn, and you can only do so by having experiences with different real life cases.
Pega is very specific for business process management, making it easier for companies to have a core platform that handles all the business processes, allows them to integrate with other systems in their enterprise structure, and their customers or employees can do this in a centralised manner. Some processes are automated, and if it’s not a process, we would have to model it as such because otherwise, it doesn’t make too much sense.
There are other products, like Pega decisioning or customer service that tackles how to approach your customers and their needs. It allows you to extract information from the data that helps you decide what Pega calls the Next Best Action. In that product, for example, you can upsell, cross sell, and use all that data to try to optimize your profit while improving customer satisfaction.
Companies need to choose what technologies they require based on their use, and then you can integrate Pega and include it in this ecosystem of your software architecture.
In my experience, it’s usually back office tasks. For example, if employees have to deal with the traffic systems, they would first get the incidents, process the fines, investigate who were the people involved, or review if there are any exceptions to the usual process. These types of processes were done manually before, and had a lot of different steps and tasks carried out by different people. By using Pega, you have all that in the same platform, some of the steps are automated, others are not. In the end, the process remains same, but in a centralised platform through Pega
Some projects can involve the commissioning of a legacy system.
Since most of the companies are very experienced, they have their own systems and some of these functionalities and features they want to improve, or decommission the whole system and use Pega instead.
As consultants, we have to analyze what these legacy systems were doing and how to implement it in Pega, whether it makes sense to do it in Pega, as well as thinking how we can leverage what was in the legacy systems, the integrations, as well as other systems in the company. Eventually, you have to decide what is going to happen in Pega and outside of it.
It’s quite important to ask the right questions in order to understand the intention of the companies and the purpose of that software. Understanding how they are doing things, how have they been working so far, what they want to achieve, and why. It’s necessary to use these questions to drive the development, the implementation and design.
Sometimes the project has already been planned, but you might find gaps, and you can actually plan the design in a better way that fits the needs of the business, before starting with the project, or before you start with certain features or components.
If you do an implementation, you want the users to find it useful.
I would say that the project I have liked the most is the one I’m currently working on because it’s a successful Pega application that has been used for years, on a daily basis, for process management. It makes sense, it has a lot of systems and microservices integrated doing other tasks, and it works in a nice way.
I was in a project where I was more involved in the design of the application, taking care of the best practices and planning the development efforts.
The company already had some features, but the application needed more planning. It took a few weeks to discuss what they wanted to achieve, how the users wanted to use it, the different roles of users, and their feature plan. We started taking the approach of modelling the features as processes, as Pega cases, in order for them to leverage the product, because the overall purpose should be to take advantage of its main strengths.
There is a company that apart from the Pega platform, they have these field services applications that are used by their employees to keep track of their work. The client has two field services applications, we are implementing the third one and they would want to implement a fourth application.
After analyzing what these applications do and what the Pega products are intended for, one of my proposals was not to implement four different applications that do very similar things, but to implement a framework application to try to follow the best practices of reusability, reducing the development efforts and not duplicating code or features. Basically, trying to keep it as simple as possible, while using the product as intended.