Archive for the 'IT Management' Category


Data Migration – Legacy System Extraction Tool

We are working on a data migration strategy to migrate current 2 years’ financial transactions to the new system.  In between, we need to determine what are the transaction data/tables and master configuration data/tables to extract from today’s legacy system over to the new one.  One concern is how to get the extracted tables to map onto 1 or more excel/CSV templates which are those that map and migrates over to the new system.

The engineer suggests we obtain the new system’s current data dictionary, share with the legacy system’s vendor to design the extraction tool to follow the new system’s structure. This will use as a supporting tool to validate the correctness and integrity of the extraction tool.

We looked onto the types of data to migrate over to the new financial system and below are the few identified:

  1. Aging ARs (Accounts Receivables) and APs (Accounts Payables).
  2. Opening balances
  3. Master data (Fixed Assets, Suppliers, Customers, etc).  Note: The fixed assets data may not need to migrate over as doing so may results double-entries of assets depreciation to the new system.

Good job, team!


Web Content Clean Up – The Big Picture

It was a very intense work week for both my team and the business users with regards to the web content clean-up exercise.  The master list is not keep up-to-date by users, no proper instructions from IT on how and what to do, IT did not inform the business users on the exact clean-up and validation activity; all these reasons are some of those being discussed with the business users as they are angry and uncertain how these activities are impacting the daily operations without being noticed of how IT is going to do it in the first place.

Assumptions were made. No back-up of the codes changes or folder structures that IT has modified that results no roll-back procedures to revert the original code.  This is the first time I heard that my team is not prepared for this activity and this is a high-risk factor for this project’s success.  EVen we argue with business their UAT copy is not the latest/updated copy, the point is that we IT should provide them guidelines how to do it.  With the recent UAT copy, the team should have done the following:

  1. Make a copy of all merchants on the production site by a specific cut-off date.
  2. Compare the UAT copy against the production site.  Take notes if all merchants in the UAT copy are complete and to verify if any missing in the list from Production.
  3. Ensure all merchants in UAT are available and completed in the UAT environment.  Any edit or deletion of merchant to be on-hold.  This is to ensure all active merchants and their offer pages are available and complete in UAT environment.
  4. Compare production list if any missing merchant is missing in UAT after verification from UAT copy.
  5. Compare the UAT copy against production to see if any production merchants are missing from UAT.  Upcoming/new merchants are not supposed to add to the UAT copy or master list at this time.

Forget about all the arguments, finger-pointings.  We need to move on to resolve the issue and get daily operation back on line.


How to work out the Service Level Agreement Document

Time is rush, the service manage has to get the service support document done within 3 weeks to deliver and get service support team to be ready for the 1 month’s warranty period before official handover of the application to them.  Sound ridiculous? Not really, it happens everywhere, in any other workplace where most project managers also forget about these important procedures prior to handover the solution to the service support team.

No panic button required here.  There are few project documents and activities to look at (if they have already prepared) to get the service manager to start to work with the support team in understand what to draft for the service level agreement document for a new application.  They are:

  • Technical specification document of the application
  • Business process documents involves the usage of this new application
  • Common issues troubleshooting guide – this helps the new support team to understand how to solve the technical issues faced during the whole project phase in case they happens again
  • Training – do ensure that the support team is invited to attend any new system training as planned in the project plan.

We must treat a service level agreement document as a legal, contractual document between the service provider and the Customer.  Therefore it must be reviewed, understood and approved by both the parties.  We also need to take note that we need to include the relevant information into the document as much as possible, and to be specific, concise and clear to everyone.

The most common mistakes that are made in drafting the service level agreement (SLA) document are:

  1. Missing descriptions of the services or applications to be supported
  2. Missing exact roles and responsibilities of the Customer and the service provider
  3. Geographic locations and time-zones details should the application is supported in a centralized support model (also known as ‘around-the-sun’)
  4. Working hours for specific locations
  5. No specific, clear escalation process
  6. Highlights on the different impacts (business impact) for each priority
  7. No communication mode for notice periods and escalation contacts
  8. Ambiguous service desk targets
  9. Missing reports metrics

With the above, we are on-track to cover all the required information into the document and share with the stakeholders for approval with minimal changes.  No pressure! 🙂


Drafting A Service Support Document

In all support processes, most organisations looks at multi-level technical support.  The reason for such multi-level structure is to provide best possible service to support the customer efficiently. Typically we always look at 3 level of service support structure is suffice – frontline (Tier 1), advance support (Tier 2) and development (Tier 3).  In most cases, activities for Tier 3 also comprise to perform problem management and change management processes.

These information are to include in this document:

  1. Understand the infrastructure design of the solution(s)
  2. Under the functionalities of the solution(s)
  3. Describe the services to be supported
  4. Define the support scopes for each level
  5. Define the roles and responsibilities of the IT support and Customer
  6. Use version control to track  the changes made
  7. Include escalation processes/workflows
  8. Review period of the document
  9. Define the IT support availability/working hours.  This has to align with the business operation hours if necessary.
  10. Define the prioritization table (Priority vs Impact vs Resolution Time)
  11. Communication of downtimes and escalation contacts

With the above, you can easily write out a good draft of the service support document without facing ‘writer block’ 🙂


Feasibility Study – Suppliers’ ASN Reconcilation

When we perform VMI (Vendor Managed Inventory) receiving at our warehouse and perform receiving of the shipments based on the shipment documents, the electronic feeds from the suppliers do not include ASN (Advance Shipment Notice) information.  We need to perform the suppliers and ASNs’ reconciliation from our customer’s planning and forecast application, and triggers the receipt feeds back to this application as well.

To-Be Process

In this case when the valid supplier/vendor does not have ASN we are to manually create an ASN and send the Receipt feed to the Planning and Forecasting system.  If the reference numbers in the receipt feed will not match that application’s ASN number, the application is able to determine that the receipt has been manually created.

Work flows:

  1. User logins to the Planning and Forecasting application
  2. Search for the expecting ASN
  3. Down load an ASN as tab delimited flag format and save it on local PC
  4. Generate an ASN into WMS (warehouse management system) and receive the shipment after physical inspection.
  5. After receiving, extract Receipt feed in WMS with ASN Numbers
  6. Upload the feed into the Planning and Forecasting ftp Server.

Implementation Design for a Regional WMS Solution

We were discussing with our solution team about the implemenation design for the regional WMS (warehouse management system) .  With the tight timeline to achieve and without any confirmed system design to work on, the Management agreed to go forward with a localised platform (stand-alone, single instance) and using this solution to deploy to other sites that may needs double-bytes/UTF-8 encoding.

We have reviewed the possibility to move forward to a centralised solution,  and to host in a site centrally accessible by the countries.  The contraints we have identified what we need to do to see if it is feasible to do centralised solution.

Points taken for considering a Centralized Solution:

  • The cost of purchasing the WMS application’s software license
  • The support structure, change management and SLA (service level agreement.
  • Multi-language support example to support UTF-8 encoding/double bytes characters.
  • Interfacing with local systems (country-specific)
  • Network performance
  • Inclusion of data manipulation from the web service
  • Centralised Hosting of the application server, database server, web server and possible RF (radio frequency) application at one site.

Fast-tracking the development work with additional resources

Full-fletch solution to be completed in 3 months.  Unrealistic but this is what we promised to deliver for the Customer to save the business.  We have analysed and it is not possible to do iterative development as this is a new, full-fetched system and it has to be delivered as a complete package.

Lots of the activities  are to do in parallel with the development work, possibly the test cases, test data, training etc.  I am worried with the one month’s testing (both SIT and UAT) to be done in the whole month of December.  Project team members have to work overtime and not sure how much resources we need to cover some of the project activities.

The difficult portion of the development is how to spilt the modules to the assigned 6 resources to do the development work and importantly to define the roles and responsiblities for each of the project team member assigned so that we can quickly resolve any disputes on the resources’ skillsets and expectations.

Next I have to review the project cost for the additional inshore and offsource resources, not to mention the travel cost as well for the lodgings and any allowances that the resources may need to claim when they are to reside in Australia for 2 to 3 months period for the project.

The biggest risk of all is that we do not have enough time to do comprehensive testings of all the modules and we are at the big risk that we may experience unforseen system issues when we cutover the new system in early January 2010.  Everyone wants to rush and get the system out on time but we need to do testing to ensure we are able to deliver quality solution to the Customer.  If we do not do well, this will bring more dissatisfaction for the Customer but the Management is aware and we all have agreed that this is the risk we need to take.  But they do not understand the pressure and stress this have put outfront to my project team members and this is very unhealthy.

Counting down, 4 months to complete all planned project activities and this is another project failure I am working towards to.

November 2017
« Mar    


Enter your email address to subscribe to this blog and receive notifications of new posts by email.

Join 443 other followers