DWS understands that you may be preparing for your upgrade, you may be mid-upgrade or even post-upgrade, and that all these stages of an upgrade project have their own challenges to overcome.
Let’s assume you are underway with your upgrade project, currently embarking on the technical upgrade, or have even completed the upgrade and are beginning the testing/rollout phases, then our Assure services can help you to achieve accurate results faster and much more cost-effectively.
We have two service options, you may choose one or both:
-
Post Upgrade Audit
Our “extract” executable is sent to your E1 technical staff, typically a System Administrator. The executable interrogates both the Production environment in the From-Release and (optionally) the upgraded environment if you have completed the upgrade. The Audit Service confirms that all modified objects existing in the From Release have been upgraded to the To Release. It will highlight objects with modifications that you may have missed during the upgrade planning process and will match against those you’ve upgraded. This service also reviews the upgraded objects, optimizing the results to ensure your upgraded system contains only relevant objects. It classifies your modification “types” and provides a solid basis for ongoing Change Management.Post Upgrade QA
Our “extract” executable interrogates the upgraded environment. The QA Service performs a quality-assurance process over the upgraded objects, highlighting all known technical/development upgrade issues prior to your testing.
Value Proposition
Upgrades of JDE E1 systems commonly feature technical issues that hinder upgrade projects and inevitably cost more time & money.
These unforeseen issues are frustrating to management and technical staff alike. They are notoriously difficult to spot without manual intervention involving many long weeks of effort.
DWS offers the DWSDimension, Advantage and Assure services to eliminate these issues as much as possible, in an automated process/service that takes just a number of days to complete, potentially saving you many weeks of additional development and testing time. The aim of these services is to discover, highlight and remove the common issues facing all upgrading JDE E1 customers.
Post Upgrade Audit- Precise identification of ALL genuine modifications in the From-Release, including objects you may have missed during upgrade-planning (a very common situation).
- Includes the identification of mods made at the version level (version overrides), which is not possible to track/identify in standard JDE, unless the customer has excellent documentation standards.
- Identifies anomalies - objects that potentially do not require upgrading.
- Identifies reports and versions that have not been run for a specified number of months – again, these are objects that may not require upgrading (or if upgraded, can be dropped from the modification set).
- Identifies objects that are “copies of standard” and confirms the most appropriate method of upgrading these (usually complex) modification types.
- De-risks the whole ‘mods’ component of the upgrade .
- Increases customer productivity as they are not upgrading/testing unnecessary objects
- If the upgrade development work has been completed, Post Upgrade Audit can also extract the upgraded modifications from the To-Release, comparing them to the From-Release’s objects at an extremely low-level of detail (everything from complicated/large changes to objects through to a field that has moved a single pixel in any direction, and everything in-between). Whilst suited more to the “upgrade as-is” JDE customer, the Post Upgrade Audit service as a whole has benefits also for those customers who underwent re-design work or business-process re-engineering during the upgrade.
- In this economic climate, certainty is a rare commodity. DWS guarantees a fixed price for the Post Upgrade Audit service and for the actual upgrade should the customer require this.
- Precise identification of ALL genuine modifications in the To-Release, including the identification of modifications made at the version level (version overrides), which is not possible to track/identify in standard JDE, unless the customer has excellent documentation standards.
- Identifies/documents objects that are “copies of standard” for future reference.
- Provides a “baseline” optimum object list, for future Change Management procedures.
- Modified objects are grouped by modification type for future reference.
- DWS guarantees a fixed price service for the Post Upgrade QA service
- Precise identification and detailed (automated) analysis of ALL genuine modifications in the To-Release, including modifications made at the version level (version overrides).
- Performs a quality-assurance process over the upgraded objects, highlighting all known technical/development upgrade issues including, but not limited to:
Quality-Assurance Check |
Notes |
Orphans |
Highlights all orphan objects. That is, objects (typically functions, structures, tables, business-views) not used by any other object in the system. These are often upgraded unnecessarily and should be removed from the to-release. |
Unusual Naming Conventions |
Identifies any objects that were upgraded with non-standard naming conventions. |
Unknown Objects |
Sometimes objects called by objects contain a missing spec/link and become “unknown” to the calling object. These can appear ok when viewed within ER design, and do not become apparent until testing finds a problem. Post Upgrade QA highlights these issues. |
Obsolete Objects |
It is relatively common for JDE to “retire” objects (usually Business Functions) between releases. The larger the gap between your From and To release, the more likely you are to use obsolete objects. These objects may exist and may run, but do not utilise std-JDE functionality (or may indeed cause problems). Post Upgrade QA identifies these objects and their usage from custom modifications. |
Bad Table Indexes |
This very common issue occurs when “table-IO” logic employs indexes that have changed between releases. Perhaps JDE has added indexes to a table, or re-arranged the index sequence, or your custom indexes (on std-JDE tables) now clash with JDE indexes – in fact all these scenarios are possible on a single table! |
Bad Conditioning Statements |
The CNC/technical upgrade of JDE code contains a known issue. Some conditioning statements in ER code are “lost”. They can appear ok when viewed within ER design, but do not become apparent until testing finds a problem. Post Upgrade QA highlights these issues. |
Client-specific Rules |
As part of upgrade planning it is common for clients to retire some objects, or replace them with other objects. Post Upgrade QA can be used to search for usage of the old objects – should they have not been caught during the upgrade. |
Use of Colour |
The use of colour in grids and forms (when on a Windows-based JDE release) will not function under HTML-based releases. Post Upgrade QA identifies these occurrences for correction. |
Bad Advanced Assignment Functions |
Certain “Advanced Assignment” functions do not operate under HTML in the same way as they did under Windows. Post Upgrade QA identifies these occurrences. |
Client-Only Functions |
Client-Only Functions, under an HTML-based environment – should be highlighted prior to testing. |
Customer Specific Checks |
We can add customer specific validation checks such as looking for the occurrence of a particular custom table, alias, DD item, business function etc across the entire object set. These would be particular to your set up. |