Implementing ERP systems

Its been a long long time since I blogged last in 2010,  Back to blogging again with something other then testing

Implementing ERP systems is a tedious task and can take months and months eventually ending up in the disinterest of all the involved parties and can end up in failure. There are cases when long time duration have heated arguments among the involved parties and this eventually ended up in the closure of the project resulting in revenue loss to all the involved parties. However we can avoid such cases and the whole implementation process can be simplified by applying a properly planned process which includes defined steps , roles & responsibilities along with extensive documentation as and when needed. 

Let’s look at defined approach of ERP implementation. 

To start with the process starts with sales team identifying the prospective customer / references looking for a ERP. In my opinion this is the entry point of implementation process. Here sales & pre sales demo team should take proper care in understanding actual requirements of the prospective customers during the demonstration / interaction sessions. Team should be capable enough to evaluate the customer needs and should further communicate their finding to the team who will actually take care of the implementation process further. One important point here is to have behavioral study of the customer team also and any specific observed traits like reservation regarding the new/existing products , reluctance should be communicated further so that the team doing actual implementation should take care of such traits. Believe me these factors also contributes to the success of implementation and success of products usage in future.

Another important factor during the sales/pre-sales discussion is the commitment made to the customers. Sales team should have a clear understanding of capabilities of development team, technological constraints if any and the existing process of vendor (Company to which they belong to). Over commitment is again a major… major factor in success. I would like to share a incident here from my experience during the demo sales team promised to customer to convert data from existing legacy system version X to make it compatible and export it further into our system but when actual implementation started it was found that development team does not converts data from version X. There was a clear miscommunication and over commitment from the sales team which resulted into initial bitterness in relations between the client and vendor.

So the key here is clear understanding of the legacy system & existing process, expectations from the new system, commitment in the defined boundaries and the finding should be properly communicated further to the team coming next - the team who will be actually implementing the system. Anything not taken care by standard sold product and can be achieved technically should be properly communicated as “Customized Solution”

Moving further, now when sales team task is over we move on next to the team who will be actually implementing the system (Vendor) and evaluating it (Client’s team). The key to the successful implementation is the commitment of all the involved parties. Things should be open as possible and no communication gap / reservations should be there. A piece of advice here for both vendor and client is to choose the respective team carefully and team members should have ample domain knowledge, process knowledge and understanding of current requirements. Support from top management is also a key factor here.

Lets talk about the various steps which needs to be followed for successful implementation. 

1  1.  First step towards the final implementation is to understand the customer’s requirements. A thorough study of the customers actual business process should be made. Sessions with respective teams, inspection of actual site and interaction with blue collar team are proven methods in this phase. Every report should be gathered along with any specific format. Legal process and government regulations if any also needs to be discussed. All the finding should be documented in a proper requirement document and should be verified from the concerned team and Sign Off should be taken. Any customizations should be understood and discussed properly. Any scope/opportunity of improvement in existing process should also be discussed and documented. This detailed requirement document is the input to the next phase and is the baseline document of the overall implementation process further. 

2   2. Next comes is designing of the system where the understanding of the requirement phase is to be mapped with the standard product’s process as to how we can achieve the documented requirement by using the existing product to be implemented. Any custom development for achieving new and specific functionalities should be communicated to development team and initiated further. We need to study the product to be implemented and customer requirement document simultaneously and map the process. s It is recommended to prepare a solution document stating the requirement and mapping it with product to be implemented such that we can trace that this is the requirement R and it can be achieved through process P by using screens S1, S2 so on. 

3. Once this mapping is over we need to develop, configure and test the system at our (vendors) both with dummy data and actual data. At this stage we can plan to take the legacy data from customer to achieve both the data conversion into proposed system compatible form and for testing the developed system on actual data. This will give us an extra level of confidence and will also help us in gaining customer’s confidence on the developed system. Results of the testing should be documented as customer may demand this and with the document in our hand we can easily share it.

4  4. By this time we are ready for the deployment. Customer should be communicated about the completion of design, development and testing so that the customer team can make necessary arrangement for deployment. In case vendor is responsible for creating necessary environment then process should be initiated and communicated to concerned team. All the necessary software procurements should be done , installed and tested in advance to avoid any eleventh hour mishap. Once all clear customer can start with the user acceptance testing (UAT). 

5   5. Once UAT is over the teams should sit together and decide on the Go live date (which can OR cannot be the date previously decided during initiation). Checklists should be prepared, existing (open) issues should be discussed and agreed upon along with resolution dates. Apart from this from the vendor end all the data migration activities should be tested and completed and at the customer end they should take necessary backups of the existing data along with the physical evaluation. Once all this is done then on fine day cut over should be done from legacy system to the new system.

6  6. One important phase in closing the implementation is Post Go Live support. This is a very tricky phase and needs to be handled carefully. In many of the organizations implementation and support teams are different. In order to be a smooth transition from implementation to support again there should be proper communication. It is recommended that a member from implementation team should be a part of support team for smooth transition. Exchange of team member helps both the support team and also the customer to be comfortable with each other.

Handling Software Product Support

Friends it has been long time since I posted last. In my opinion two most difficult fields in software industry / SDLC are “Software Testing” and “Software Implementation and Support” as both are customer facing. In this post, I am sharing my experience of software product support industry till now as to why I consider it as one of most difficult field of IT.

Software Product support is not an easy task and it takes lots of time to become productive in this field. Following are the major reasons –

1. Vast and complex nature of software - Any product implemented in a particular organization is certainly of a very vast and complex nature as they are automating major processes of the organization.

2. Customizations in standard product – Every organization has its unique needs and processes. Thus while implementing a standard industry product some customizations has to be done in standard product which implements the unique needs. This adds to the complexity of the product.

3. Change in requirements – There are sometime frequent changes in requirements and this tampers/somehow disturbs the original information flow of software. This in turn introduces new issues in software.

4. Volatile nature of software – Remember software’s are volatile. An issue which is encountered at customers end might not get replicated at support environment at all. There are also incidences that a incidence occurs just now might not occur next moment.

5. Expertise and problem defining capabilities of customer – This is also one of the major points contributing to difficulty of the job. Some customers are intelligent enough to explain the problem and resolving the queries for such is bit easy as compared to customers who are not intelligent enough and are not sure of what operation they have performed. Also there are customers who are technically sound it is easy to explain / resolve their queries. Also it is easy to make them understand the complexity and technical aspect of the problem.

6. Nature of customer – Understanding customers is very difficult. Customers are after all humans and as there are different types of humans on earth there are variants in customers too. Some customers can control there emotions and some cannot. Some report issues after doing every workaround and some don’t. Some want there work to be done on priority and does not want to wait at all and some can wait. Like wise there are as may categories of customers as there are humans on earth. A software support / technical support engineer has to handle them all.

In the coming post, I will deal with handling issues while providing support

ERP … the future

Friends, a post after long time. Here I am again sharing my experiences while working on ERP products. This post can be boring but since this is a theoretical concept so cant help in that.
ERP or Enterprise Resource Planning, as the name suggests is a software package designed and developed to plan all the resources of an enterprise effectively. These resources can be Financial Resources, Human Resources, material resources and others. A ERP package software addresses the enterprise needs of an organization by tightly integrating the various functions of an organization using a process view of the organization. The activities supported by ERP systems include all core functions of an enterprise, including financial management, human resources management, and operations. Major reasons organization going for / advantages of an ERP product are –
- Integration of interrelated information.
- Integration of end to end business processes.
- Standardize and speed up organizational processes.
- Reducing complexity.
- Centralized information source
- Security
Interestingly, above are also the points why organizations are reluctant in installing the ERP system in there facilities as because of these reasons results in decrease of departmental myopia and also the habit of putting work on others shoulders.
We will try to understand all the above points by an example. Visualize an industry process of manufacturing, storing (Inventory) and selling of an item. Now we start from back, a sales person enters a sales order in the system for item X with quantity Q then the inventory in charge should come to know that Q is committed to sales for item X. Further consider that there is minimum stock which is to be maintained for item X and if processing of this sales order decreases the inventory below the minimum stock quantity then the production in charge should be intimated to start production of item X. in turn purchase department should be intimated to purchase the required raw material. Below is a diagram depicting this flow –

Coming back to above points, ERP automates, integrates this information flow and the business process as well. It also standardizes and reduces the process complexity. Above all, all this information is stored at centralized place and is secured by user privileges.

A quick point on testing ERP software, apart form the normal functionality a tester has to test the business process and the integration of the information among the interrelated modules.

Spice QT-66 Usability Issues

Friends,

Nothing much to write about in this post as this is just a small sharing of information in reference to usability of mobile phones.

Recently, I bought Spice mobile QT-66 just two months back. This is the first time I am using any phone other than Noika. While using spice one, I observed two unusual things both in terms of normal usability and also when compared to Nokia devices. Observations are -

Whenever I disconnect a call without attending it then usually in Nokia devices this goes into RECEIVE CALLS but in my spice device the screen displays MISSED CALL and the entry also goes into the same option (MISSED CALLS)
Second observation is regarding the MESSAGE functionality. Whenever, I reply/type a message and then I opted to end the message screen by pressing the END key then the message gets saved into the OUTBOX folder. Usually it should be in DRAFT folder as per my usage of other devices / messaging software’s

Comments awaited on this…………………

ICICI Bank ATM bug … Try it!.............

Friends, apologies as I am updating the blog after a very long gap of almost 2+ months. Anyways, just thought of sharing some interesting observation I found today. (Apologies again as being a tester I would have found this earlier but no body tries to play with their own money so neither did I : ) )
Recently I went onto an ICICI bank ATM for doing some transaction. I noticed one interesting bug over there. I want all of you to try that only once because if you try it for 3 times consecutively your card will be blocked and I am not responsible for that. Anyways, here is what I noticed –
PREREQUISITE - You must have changed your ATM PIN once.
1. Insert the card
2. Enter the old PIN , the one provided by the bank initially
Notice that you will be presented the transaction selection screen
3. Select any transaction, say balance enquiry / any other from the available options
Notice that now you will be prompted that you have entered wrong PIN and the machine will ask for the correct one.
4. Enter the correct PIN and then you will proceed towards the completion of your transaction

Comments awaited on this obsercation as to whether this is a bug OR not . In my opinion , its a high priority Low sivierity BUG

Amit