NAV 2009 & NAV 2015 technical consultant - August 2024
remote, remote
For one of our clients we are looking for a NAV 2009 & NAV 2015 technical consultant
Overview:
Short description of the project: the client is running an antiquated version of software NAV 2009 in Latin America internally called “RBO”. The client plans to replace it with a combination of “aLS” (NAV 2015) – ERP & LS Central PoS.
“RBO” & “aLS” are client customized solutions. The project must split ERP & PoS functionalities to enable another strategic program for the company planned for next years and ensure legal & fiscal compliance in these highly fiscal countries.
The LS Central project is being run in a Scrum/Agile methodology, incorporating sprint planning. This agile approach enhances client project's adaptability and responsiveness to changing requirements and evolving business needs.
Background: As part of the project, the client plans to decommission the old version “RBO” (NAV 2009) and update it to the new Version “aLS” (NAV 2015 & LS Central) This includes, among other things, retrospective checks and backup work on NAV 2009, migrating data between NAV 2009 & NAV 2015, the configuration of the NAV 2015 system based on 2009 & (further) development of software code for the purpose of use for integrating the code in the new aLS version. Consequently, the client does not have own employees with sufficient expertise in connection with the configuration & development of aLS and for this reason requires external expertise. The contractor must have expertise in a very old version of the system – NAV 2009 which is no longer used by vast majority of the market therefore the contractor has a unique position and provides significantly different services than the internal staff.
Tasks:
Provision of a detailed delivery plan via JIRA Tickets, which is drawn up based on the contractor's own expertise. The plan is approved by the client.
Jira tickets maintenance based on contractors’ own expertise. This includes a project related update within the agile ceremonies on the process of the tickets to discuss progress and identify blockers.
Completion of the configuration (sometimes coding) which have met all functional and technical specifications and have therefore been approved by the client. The configuration (sometimes coding) are made available to the contractor via Jira Tickets for processing.
Inclusion of Content is available via the Jira and Confluence. The content to be processed is made available to the contractor to discuss progress and identify blockers via agile updates (named above). Content will be saved on confluence pages to be picked up for working on in Jira Tickets.
Processing of the tasks provided via ticket:
Every approaching ticket in Jira needs to be tested. Developer can be an internal or an external. If it is an external, the contractor will act as an external consultant. If an error occurs during the testing another ticket will be raised against the other internals testers. The testing takes place in an testing environment provided by the client
Resolution of coding and configuration issues identified in testing
Errors needs to be solved by contractor’s own expertise.
Creation of a process description based on your own expertise. The creation process description is provided by the contractor via Confluence and accepted by the client.
To compile detailed unit testing report to present to client for review/approval
Review meetings are once in four weeks. There the test process will be shown to the whole team. The contractor can choose how to present it to the team. Possible via PowerPoint or as a demo in the coding tool itself (provided by client).
To compile a basic configuration/developer testing report to present to the client for review/approval needs to be documented in the testing Jira ticket. Presented to the client via the production Environment from LS Central in agile Ceremony meeting (mentioned above).
To point out dependencies and potential problems which may occur in the configuration/developing or testing process via Jira. Reporting this to the client to get input or advice within in agile Ceremony meeting (mentioned above). In Case of an error the resolution to be based on own expertise. In case of dependencies hand over to the client is needed.