How we work with Dynamic NAV
We love the power, flexibility and usability of Dynamics NAV and we get a real buzz from our clients using the system to improve their businesses. We are also under no illusion that only a well implemented system will achieve this improvement. That is why we use our experience to ensure that every project, large or small, is properly planned, designed and implemented.
Probitas has a proven track record of:
- Implementing Dynamics NAV in a wide spectrum of market sectors
- Delivering customisation to add additional business-focused functionality
- Providing on-going support
- Delivering cost-effective upgrades taking advantage of the latest technologies and functionality
The initial parameter to consider on any NAV implementation, which fundamentally drives the entire project, is to define up-front the type of implementation.
Upgrade - to the latest version of NAV– basically this involves taking all the customers’ existing NAV data and customisation code and moving/upgrading it to the latest version of NAV.
Re-Implement - basically this process involves:
- Reviewing your business process you require today and mapping them to the functionality in the latest NAV version
- Reviewing and filtering existing data before importing it into the new NAV
- Allows the customer to revert back to Standard Code, dumping their old bespoke code
Initial/New NAV Implementation – this is like a Re-Implementation except that the old ERP system is not Dynamics NAV.
SureStep is Microsoft methodology for implementation. Probitas follows this methodology adapting it to fit the individual customer's requirements. Our project managers are Microsoft Certified in SureStep.
Agile vs. Waterfall
Probitas use both a waterfall and agile approach depending on a balance between speed, control, resourcing, budget and scale. A waterfall approach lending itself to a project with clear requirements and a rigid timescale, whereas a more streamlined agile method is adopted where requirements are initially unclear or subject to change and a multi-phased implementation is expected.
RapidStart is a series of Tools within Dynamics NAV which assist in the setup of a new company.
At the core of RapidStart is the ability to create Excel spreadsheets specifically for set Tables in NAV. For example, you can create a spreadsheet with all the Item Table fields. This sheet can then be populated with the Client's Item data. Importing this spreadsheet back into NAV involves a validation stage with RapidStart which ensures data integrity.
A key aspect of this process is that it can be carried out and managed by the customer, streamlining the Data Migration process and significantly reducing costs.
At Probitas, we feel that this new area of functionality within Dynamics that will continue to grow and expand in future releases – watch this space!
In addition, the RapidStart functionality can be used after GO-LIVE to support some aspects of the business processes, for example:
- Mass adjustment of the MRP Planning parameters on the Item card
- Managing the process of reducing Inventory by updating Item planning parameters
- Importing simple EDI messages
Conference Room Pilot
At Probitas, we strongly believe that a major element of any successful implementation is the Conference Room Pilot (CRP), to the extent that we insist on running at least one CRP before creating the detailed GO-LIVE plan. A pre-requisite for the CRP is:
- Business data loaded into NAV
- New business process documented in the “Ways of Working”
The purpose of the CRP is to get the end users to walk through their day to day business process, following their new business Ways of Working. This effectively proves to the Project Team and the business that NAV has been configured / set up to support the Company's new ways of working.
During the CRP, any issues are highlighted and a corrective action plan is created. On resolving the issue, a mini CRP is re-run to ensure the business process is not compromised.
Using this methodology the entire business process is tested and proven by the client's staff using their data.
Typically, Probitas projects will use the controls that are detailed in the Surestep methodology, but tailored according to the scale and complexity, speed of implementation required and resources available.
This acknowledges that not all implementations are the same and not every change is small. This means that the approach can be tailored and scaled to ensure a project does not get immersed into its own bureaucracy.
Probitas use both a waterfall and agile approach depending on a balance between speed, control, resourcing, budget and scale, a waterfall approach lending itself to a project with clear requirements and a rigid timescale, and a more streamlined agile method where requirements are initially unclear or subject to change and a multi-phased implementation is expected.
A large-scale project would be assigned a dedicated Probitas resource to support the client's internal processes and Project Management function; they would also be able to provide assistance and resource cover to the Lead Consultant. For smaller scale projects the Lead Consultant will often facilitate the required planning and controls adherence in conjunction with the client.
A more dynamic change or a faster implementation would benefit from a more agile approach where the objectives and end result can be broken into clearly defined sprints with an expected output, control metrics and assigned resources. This can be beneficial when a faster delivery is preferable to waiting for perfection.
Probitas use a formal Change Request document to manage code changes. Depending on the complexity of the change these documents can be just a few pages to several hundred pages.
All our Change Request documents follow a standard structure:
- Summary - a short summary and reason for the change as well as the total price
- Introduction - a short explanation of the change and more importantly the purpose of the change
- Functional Requirements - an explanation of the business requirements and how we are going to deliver the solutions using business terminology
- Technical Design - the detailed technical specification which will be used by the developer in conjunction with the Functional Requirements
- Testing - the testing that is required. It is important to determine if Regression Testing is required. Regression Testing is required when the area or system as a whole must be tested and does not replace Unit or Functional Testing.
- Charging - a breakdown of the Change Request costs from a Design, Development & Testing point of view