You always want to start working with RPAS but don’t know what options you have, let me say you are not alone with this question. Some people ask us who want to work with RPAS, but often they don’t have ideia about it or don’t find a clear information where to start.
So this post will help you understand better which they are key roles that exist when you work with the RPAS. We separated some important informations and the main profiles that anyone can get involved with RPAS.
Although it’s a technology that few people work, the roles are very similar to other technologies in the market, there are some small variations, but as there are too many questions, We’re here to write a little about them.
First we let’s define a set of roles we have within the RPAS and then we will explain how we can achieve each.
This is the starting point for those who want to work with RPAS. A person who wanted to learn all RPAS concepts should start here, need to be Configuration. Thus that person would be able to understand all the points (concepts and practices) within the RPAS.
This person is responsible for maintaining all configuration, for example, to create/change/remove measures, rules, rule groups, workbooks, etc .; In this role the person could learn more about the binaries and libraries that exist in the RPAS.
In various activities involving RPAS is always needed this skill, Configuration, because configuration maintenance is continuous.
While it’s very common for other technologies you start as developer, within the RPAS this position is rather complicated. It happens due to the fact that the source code of RPAS (libraries and binaries) is owned and exclusive liability of Oracle.
Although there is this restriction of Oracle, there is a way to develop own libraries and functions within the RPAS; This feature may be developed for a customer, create a new solution or library; but even so, it’s hardly rare to find people who work with it.
Due to the above both points, it may be possible to count by hand the number of people who may be considered purely Development in RPAS. Of course this doesn’t mean that many people identify themselves as Development to make a direct relation with other technologies.
Functional has a responsibility to understand quite clearly a process within a specific solution, knowing its rules and operations of the process and understand the input and output information within the process flow.
It’s very important that the professional know identify mistakes and knows how to use the tool to perform all the steps necessary for the proceedings. So there is always an extensive question whether a functional need to know or not about the “technical stuff”?
Well, for me, I believe the Functional needs to know about technical stuff to know details to trace calculations, understand the formulas, validate the process and observing if something isn’t running correctly, but has people who think otherwise.
An important point about it, each solution has your functional. So it’s not easy to find a person can be functional to many solutions. It happens because the knowledge and experience of the resources used by each solution is extensive.
For example, the MFP isn’t a solution where we have a closed vision from Oracle about of all processes, we need to recheck all processes about financial planning. While products like RDF, knowing the functionality is the differential of a functional.
A Technical has a very similar responsibility of Functional but of course with more responsibility on the technical side, especially in the organization and structuring of all technical issues involving the RPAS.
Sometimes Technical has a very close of Business, with business domain, but often lacks experience in many business situations. Often the Technical comes from technical developments within the tool and therefore may analyze various issues through a technical perspective.
A Technical can support alone a solution along with other technical and business teams. His knowledge answers questions of everyday life of a solution like managing and fixing production incidents, direct support to users and definition of improvements within a solution.
Business has a very responsibility like Functional, but much larger. He understands all phases of a solution and its operations, is able to explain all macro and micro activities of a solution.
Always Business will be the person responsible for defining all steps and operations that we have within the solution. Given his experience, he’s able to explain in detail each activity that exists within some solution and indicate the best way to do something.
Many people ask if Business needs to know or not about the “technical stuff”; Here I can agree! I consider Business has knowledge of Oracle RPAS platform as differential, but it isn’t mandatory
Architect is responsible for organizing all business and technical issues involving a project, from development to delivery, through integration and flow of data and processes. He gets involved with various areas within a company, for example areas such as BI, integration, store operations, etc.
Often an Architect knows of the whole process within a solution, but has no responsibility to ensure all details with precision; he would be responsible for defining the macro activities within a solution, but wouldn’t be responsible for defining how they will be made, but would validate the result.
Although the focus is RPAS, it’s great importance that an architect has the knowledge of the structure of the data between the various solutions (MOM, BI, etc.) so you can provide a well integrated solution of the whole process (macro/micro vision).
Well, now we have all roles that need to understand. It’s important to remember that every consulting or retailers can give a different name for one of these functions. For example, a SYSDBA wants to work with RPAS will get a role as Technical but he needs to know more details about the solution.
How and where to get the knowledge for each role?
That’s an interesting double question! Let’s start then how to get knowledge? There is no other way if we don’t study! There are two lines that we have: 1) learn more about the business itself, and 2) learn more about the platform and solutions.
Option 1) allows to learn much more about the business itself, understanding the concepts, calculation rules and operation. It’s much better to do some training, graduate or undergraduate degree in a business area, so you’ll have set of concepts and information that the tool will be unable to provide directly to you.
Another possibility in this context is to experience the daily life of a retailer, whether large or small, being employed or have an activity in retail. These options will provide you with an intense vision and knowledge of how retail works, learning and understanding how each activity there is.
No wonder that due to living within a retailer, some people are invited to participate in consulting, they have a more holistic view of the processes and activities that involve planning and operation within the retail.
Option 2 is to learn more about the tools and how it is organized and structured to meet a solution. At this point Oracle provides the Boot Camps for those interested in learning. Within the Boot Camps you can go through all functional and technical points involved.
The Boot Camps are dedicated features and enhancements of Oracle products, often people who work directly with the product may not have a great use of the material being exposed, but learn is always is good!
Another important point of Boot Camp is that you don’t learn too much things you need of everyday life of a tool; normally these needs are quite operational and are often associated support activities; for someone who works with RPAS it’s recommended much more Oracle Support.
Support x Consultant
A wide discussion involving any activity within the Oracle Retail is the discussion of who is better?! who is more competent, the Support or Consultant? The answer is simple, depend of what you need to do!
It’s fact that the domain of someone working in Support has knowledge about issues of everyday life and an ability to solve them quickly, it’s a knowledge and domain that few consultants have it. It’s happens because in the support normally has a little time to solve a problem, they need to think and evaluate what happened very fast to return the service as fast as possible.
Consultant side is interesting access news features of the different solutions that exist and the ability to demonstrate flow of information and processes. This capability happens because very often Consultants engaged in initial questions and discuss projects macros issues of the solution and processes.
There is an intermediate level between Support and Consultant that would define as Support Consultant, that person would be more involved in improvements issues, change processes and also technical improvements of performance within the solution as a whole; only after a solution has been implemented we have this role.
Many companies seek the latter professional, Support Consultant, because is necessary support the business and IT staff in the evolution; The problem of this role is that your approach is extensive and require a lot of knowledge of the person who works, sometimes in different modules.
Summarize, if you have the opportunity to get involved on both sides: Support and Consultant, you will certainly have a large experience on all parts to provide the most diverse solutions to a company.
Good luck with all those who want or already work with RPAS!
PS: I’d like to say thank you my friend Daniel Pestana about many comments made about this text.