Tuesday, February 07, 2006

MY ERP Upgrade!

An important aspect to consider when you set out to build an ERP will be presented to the reader. My experience with ERP industry has been upgrades probably that drove me here. No awards for guessing the content of this post, but I certainly wish to share some thoughts on how to achieve what we desire.

Today’s ERP industry is quickly becoming a legacy system. When I set out to build MY ERP my first priority would be to look at how well the application will provide the upgrades. The question which arises to the user is, “How can you estimate your upgrade when you have not built your first release?” (Appreciate your attention!). I plan to take the non-traditional route.

When my business process specialists build the functional pieces of MY ERP, I would like them to look into other competitors and ensure that we provide all the features provided by our competitors. Once the essential pieces of my applications architecture has been built, I want the people in my organization to come up with an upgrade path from one of our competitors to our application. This application upgrade path should be 75% more efficient than our competitors upgrade path from his old release to his new release. The most important trick here is to ensure that we do not loose any valuable Customer data. Our upgrade application must have conversion scripts which will ensure smooth migration of our client from one ERP segment to the other. As always the next section will give you an example, so that my vision does not get blurred through your eyes.

The Customer is running PeopleSoft and using the HRMS application. The Customer makes use of the HRMS product of PeopleSoft to store and manipulate his data. Our business process analysts will determine the exact location in our application where the PeopleSoft data can be used (Tedious job! But nevertheless it should not be left to the Customer). Then we will create conversion scripts to move the data from the PeopleSoft system to MY ERP. All features provided by PeopleSoft which do not exist in our system will be added to our system as Customizations. This particular script will be utilized by an upgrade Tool (Conversion Aide) which will parse the script and provide user interfaces that will ease the job of upgrade. If there are any Customizations made to the PeopleSoft system (Why did I put an ‘If’?) then the Conversion Aide would provide suggestions to the Upgrader to handle the Customizations. E.g.: If the Customer adds a field to a particular table the Conversion Aide will identify this to be a feature which would be lost during the upgrade and hence will provide the user information related to this. It will provide the user a segment of the Conversion Road Map, which includes a pictographic representation of “how and where” the data from the Customized table gets converted. Then he will be given the option of retaining or retiring the Customization ( The Customer will require some effort to look into why the Customization was done, so the Conversion Aide will also provide him the Customization plan which would be generated by the Conversion Aide to determine “Why were the Customizations made? What is the Customization?” This would not be possible without understanding the complete architecture of PeopleSoft and what are the details to look into?). If he wishes to retain the Customization he will be prompted with another interface to apply the Customization to MY ERP. The Conversion Aide will track the Customization made by the Customer and it will make the necessary changes to the conversion script. Now the Customer should be able to verify the validity of the changes made by the Tool, hence it will provide a Compare Interface to validate and edit the changes.

Most of the thoughts in the previous paragraph are targeted at Customer Modified objects, what about the Customer Added objects. Here I’ll concentrate on the other aspect of Customization, the first step in handling Customer added objects is to perform a check on, why the customization was done? The Conversion Aide will start with this simple question on a user interface which will be indexed. Now when the Customer types in the reason for the Customization the Tool will search and retrieve the business process available within MY ERP for the requirement. If the Customer is satisfied with the business process provided by MY ERP then the Conversion Aide will assist him to generate the scripts required for the conversion. Else the Customer Added object from PeopleSoft will get converted into Customer Added object in MY ERP.

I certainly understand that this will require lot of effort from understanding the business process and architecture of two systems, but it will certainly save a lot of time for the Customer and increase his ROI. It will also gear us up for our own upgrade. I’ve not spoken in length about the Code section (Look closely I’ve only considered objects!). I’m an optimist when it comes to me believing the fact that code modifications can also be automated (at least to a certain extent as to ease the user effort).

“Why should I migrate?” – This will be the first question asked by the Customer when you reach him, so it’s always better that we do concentrate hard on making MY ERP a better product than what the market offers and then allow the user to migrate to the better product in a better way!

No comments: