When a supply digitization project is going to start, the first thing to do is a survey of the functional needs and one of the main objectives is the inclusion of the automation of different processes that in the current operation involve great efforts in processing time. manual. This way, existing controls are mapped and new ones are added to give insurability to the process, approval flows, additional verification checks are included, and many times this survey can be affected by technical feasibility or even by the cost-benefit relationship of making great efforts in development due to the complexity of the request.
It is very important to carry out constant checks in the process of raising the functional specifications and the technical restrictions that may exist, in order not to generate false expectations in the generation of documents that are impossible to execute.
10 automations that you should validate
Below is the list of tasks that, based on experience, should already generate an early warning to the functional team that, if they arise as a necessity in the supply digitalization project, should have technical validation before being able to advance in the definitions:
- Multi-dimensional variable approval flows
The supply digitalization project, in most cases, becomes a leverage for the general review of approval policies, which can be restrictive, pachydermic and obsolete and were created with a very different context. Having variability and multiple dimensions of dependency for approvals not only has a technical complication, but also represents friction when implementing the project , since the work tool and methodology is being changed to the approvers who have operated for a long time. time.
- Replace transactional tool tasks
It is very important to never lose sight of the fact that the digital sourcing project can be quite different from replacing functions of the transactional tool such as ERP. In digital supply, tools are implemented that allow traceability and transparency and additionally streamline processes, but it ultimately leads to the creation of a process in the ERP which cannot be replaced, given that it is the transactional tool that connects worlds such as supply and finances, which must last over time. Therefore, it cannot be assumed that sourcing digitalization tools can totally replace the transactional tool.
- Integrations with legacy systems developed in-house
Many times it is intended that systems that were custom developed by the company’s internal resources, which most likely do not have improvement maintenance tasks because it is not an important focus in their day-to-day tasks, are integrated into the supply tools. digital. As a premise, all systems can be integrated, however, the effort involved in intervening in a legacy system of this nature represents major problems in the materialization of the project.
- Integrations between systems
Continuing with the topic of integrations between systems, getting two teams with different methodologies to talk has a significant challenge. It is important to know the backlogs and availability of both tools and design a joint schedule that does not generate interference.
- Replace human concepts with automatic controls
When reviewing the tasks carried out by different people in the company, which are manual and represent great operability, they usually assume that they are 100% automatable; It is necessary to review the filigree of the task executed, since the verifications carried out by a human, who interprets, investigates, calculates, are not always automatable and one must be willing to lose some controls in case of making the decision to replace it with the digitization tool.
- Assigning tasks to available resources
It is common that in some tasks that are executed by a group of people of the same level and knowledge, an automatic distribution based on availability is intended. It is important to keep in mind that the distribution that is made possible day by day in meetings, by knowledge or by self-management are not variables that can be configured automatically and end up implementing distributions that are not feasible in practice.
- Homologize functionalities of office tools
Pretending that the digital sourcing tool executes the same functionality of a calculation tool like Excel or a text processing tool like Word , generates great complications in the developments and they will always be far from obtaining all the power of what they offer. has been achieved for decades of office tools.
- Specific or seasonal tasks
It will always be difficult to support, in the cost-benefit analysis, the implementation of the automation of tasks that are only executed once or are executed in a certain period of time. Generally, they require a lot of development resources to execute a task that could perfectly be avoided with a policy and the correct monitoring of your application by process.
- Migration of processes between non-approved tools
Imagining that the implementation of a digital sourcing tool completely replaces another that has already been implemented and is obsolete may be naive. It is very important to think about an implementation of new processes, given that migration and its continuity have a lot of friction, the replacement action already indicates that something was not working correctly with the previous tool.
- Retroactive changes to completed processes
Along the same lines as the previous point, trying to make retroactive changes in functionality to processes that have already been completed always requires an effort in development and much more in the testing teams, given that a large part of the history must be replicated to do all kinds of things. negative testing (applying invalid data to a test set)
It is very important to keep in mind that digital sourcing efforts are a joint task of the purchasing functional teams and the technology support teams to the sourcing team and only the correct meshing between these two main actors helps to minimize risks and maximize the success of the project.
