• It was a bit of a challenge to ensure the new environment after migration meets all of the compliance criteria and still remain cost effective.

• It was a bit of a challenge to ensure the new environment after migration meets all of the compliance criteria and still remain cost effective.

• The new web-based interface in Dynamics 365 F&O can be unfamiliar to users accustomed to the Dynamics AX interface, potentially leading to resistance and slower productivity during the initial phase.

• Legacy customizations in Dynamics AX might not be compatible with the new architecture and UI of Dynamics 365 F&O, requiring redesign or redevelopment.

• Migrating large volumes of historical data while ensuring its integrity and compatibility with the new system can be complex and time-consuming.

  • Implement a phased approach to data migration, beginning with high-priority data, using tools like Azure Data Factory to ensure seamless data transfer and minimal disruption.

• The new features and interface require comprehensive training for end-users to fully leverage the system, which can be time-consuming and resource-intensive.

  • Tailor training sessions to focus on the specific roles and responsibilities of different user groups to ensure effective learning and immediate application of the new UI.

• Introducing a new system can create disruption, and without a solid change management strategy, it may lead to confusion and inefficiencies.

  • To address user adoption, offer detailed training sessions, workshops, and access to user guides for staff to become familiar with the new interface and features and supported them to learn in batches with targetted based user group. 

Worked on a complex integration scenario with multiple integration tools like Mulesoft

Customer specific issues reported for each project managed via Devops, jira or confluence tasks.  

Managing multiple clients via ServiceNow portal was a bit challenging where each client has its own SAP environment.  

• Changing business requirement:  Client was not clear on how they wanted the documents to be shown. They had a TO BE version which was very different from the version they had in the system and took a lot of back and forth and updating the PDF to understand the requirement.
  •  Before starting the development we spent a couple of hrs to mock up the PDF documents with the actual data in the system to be sure on what is needed. 
• Lack of team member and ownership Client did not have any internal team of functionals, Technicals and testers who can review changes and provide a timely feedback
  • We tried our best to help advise client on the different test scenarios we included as part of Unit testing. However, it was a time-consuming process to get a reply from the client and to test the changes 
• Outdated code using SAP Scripts and Multiple language Support: Client uses SAP scripts which had been long replaced by Smartforms or Adobe forms. It had to be setup in  multiple languages. Also each required email notification to be sent in multiple language
  • A copy of the data for both the  languages was bought and a mockup of the required PDF was created. Also a scenario for different cases was created example when to send notification in German and when in English, What should be the text content to be included in each etc. 
• Budget and cost issues: Client had a fixed budget for the work and the requirement kept changing and also there was a huge delay in providing the feedback which caused month of waiting for the client to come back.
  • Some Sales order and invoice types had a different configuration in the system and did not work with the same code which was pushed. We did inform the client that this was not part of the initial requirement gathering but due to the tight budget they wanted to include everything in the same cost. We tried our best to accommodate within the price we had quoted, 

• This was a straightforward implementation where we were able to install the SAP system from the application file and database however in trying to do backup and DR testing we ran into space-related issues as the log and snapshots quickly filled up all the space available
  • It was informed to the client and the hard disk space had to be monitored closely. 
• To install the application at the right path and to create seperate client for Dev, QA and Prod we were not having enough disk space  and we also informed client to have them on a seperate server
  • It was decided to create  a partition and do multipathing and logical volume grouping so the system can have different client versions. 
• End users after implementing the S4 Hana system were not comfortable with the GUI based window and tcodes which had to be entered to navigate around in the system
  • A few training plans were made to help them understand the SAP system, Also the option of moving away from Tcode based approach to the Fiori Tile-based model however this would have delayed the project Go live plan hence was parked for later. So the client, for now, continued to up skill the existing resources and Peritos assisted wherver any help was needed.