Getting Ready for Weekend Deployment

Finally, we are getting ready to setup the new warehouse management system.  Beside installing the new WMS solution to the new server, we have a few data migration activities to migrate the data from the old system to the new one.

Perform data validation against system and physical inventory

1. Open orders (merge/pull) list
2. Open ASN (advance shipment notice) list
3. Physical Inventory count (PI Count) as of last Friday’s operation
4. Open/closed inventory list
5. Receipt list
6. Despatch list

Data Migration Activities

Pull Part Master and Deviation Files from system

Customer send Part Master and Deviation files in “SOFT COPY” to vendor

Validate Part Master is fully loaded and in sync with both systems

Send “Open Order” list to Customer for validation

Validate open orders list provided by Customer

Send “In-transit” order/inventory list to Customer for later action

Send PI count to Customer

Customer to convert inventory based upon report from existing to new system requirements (if required)

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’

Work Ethnics, Personal Health, and managing Work Bullies

Does ethnic in one’s professional work exists in our daily work activities?  One will wonder and it is hard to draw a line to understand how we can contribute to the Company and as the same time, being ethnic and partial in delivering those results.

The definition of work ethnics say that it is not just about setting values based on diligence and hard work, it means a set of virtues and know what to get things done in the right way (Reference: http://en.wikipedia.org/wiki/Work_ethic)

Should a staff being punished for her bad duties/results for ensuring things are done rightfully and in view to protect her Employer’s liability?  For the Management, they view the employee is not able to cope with the stress and they do not care for the health of the employee but only for the profits.  No matter what, the staff has to make a decision to take care of their personal health first.

Working with work bullies is inevitable and it happens all around the world.  We have to manage them and concentrate to develop our strengths to get things done and building our self-esteem.

Test Data – Tracking the discrepancies and Issues patterns

Management needs to look at statistics to understand the situation on the data discrepancies.  What I am doing is to consolidate the report to understand the behavior and frequency of the test data that are kept requesting from the Customer to create and reload into the test system for the affected test cases.

With the recent issues with the Customer’s test data preparation that are blindly dumped from Production to the test environment without proper validation , the team is going into the details of the issues. This is where we breakdown the information

1. Nos of test data requested on a specific date
2. Nos of complete test data set that is ready for testing
3. Nos of incomplete test data set that needs to clarify
4. Nos of “re-open” test data set that we need to create and reasons for failing the validation

Being a Forward Thinker and Good Decision Making Skill

Everyone will experience times when to decide  to raise an alarm to the stakeholders on any potential issues that post risk to the project schedule, cost and scope.   In fact, majority will feel that it is not the right time to do so or may feel that it is unnecessary while getting the project teams to solve those problem before the risks accumulate.  As the saying goes, the project team is supposed to solve the problems, rather than disturbing the stakeholders with trivial issues that do not post any risks at that moment.

Good decision making doesn’t means you have pointed out a good decision, rather it is the process to flag any issues for discussions and result in the decision making with the stakeholders.  Even if the decision is not made at that time, we have take the opportunity to reason, analyse and do not allow any chance for a problem to suddenly present itself as an obstacle to complete the project.

The process in decision-making involve:

1. Collects all relevant information
2. Asks for recommendations and advice from other stakeholders
3. Sets deadline before the decision must be made
4. Make the decision and announce it with the reasons behind it to all who are involved

Nobody will be a perfect decision-maker but without using the proper process to derive the reasonings, wrong reasons are dervied for the wrong decision after the project delay.

Risk Assessment for Software Project Delay

Critical bugs found in SIT, delay in other development components, inadequate test data and incomplete UAT test cases.  These are the issues that the project team have decide to raise to senior management for delaying the user acceptance testing (UAT) by 3 weeks.

Before the official communication is released to both Customer and internal management, we work out the risk assessment to justify the reasons for the proposed go-live date in February next year.  The proposal that we do covers the 5 areas of the software life cycle phases in sequence.

1. SIT Testing – unforeseen critical bugs detected and code changes required to ensure right system and solution; inadequate test data from Customer.
2. UAT Testing – Schedule changed due to task #1; resources  as  Dec 16 to Dec 30 was originally planned to be of blackout period (due to holiday/annual leaves by all team members).  Hence UAT can’t start from this period, instead postponed to early Jan.
3. User Training – Should training is conducted at the same time as UAT, users will be trained with incorrect information if bugs are found during UAT testing; the trainers are involved in the UAT testing; we only have one test environment that is used for both UAT testing and training.
4. Deployment – Development is working on data migration scripts after SIT End2End testing (12 days efforts);  system readiness is on Jan 25
5. Go-live – Operations need to stop to enable data migration that involves stock checks, validation etc for 2 days (over the weekend) on Feb 4.

Checkpoints for Test Data Validation

Before we start any testing, we need to include a milestone to validate all needed test data are setup correctly at the test environment.

Few things to be done for the various checkpoints:

• Obtain the test data’s details from the Customer
• Validate the test data against the physical test server, at the database server to ensure the information provided by the Customer are correct
• Looks into the data contents of each test record and highlight any incomplete information of that data to the Customer to verify.
• Once validated, Customer is to re-send the amended test data to the test environment.
• The test datas are to record in the UAT test plan with information on which test scenario that test data is used for that testing.
• 3 days before the exit criteria, ensure all test data are valid and can be used for testing.

Localisations for Client-side applications

When there are user requirements on localizations, we always refer to the user interface or client-side applications.  This is more on the usability and ‘look & feel’ of the user interfaces to be in the users’ native languages, the inbound data’s encoding settings that are imported from gateway to data repository and the inputs of native words into the data repository and transmit to external sources via the gateway.

1. Determine if the encoding conversion is implemented at the gateway, database or application level for inbound and outgoing data.
2. Determine the encoding and charset of the native language to use.
3. Test the encoding code to ensure native characters are displayed correctly from inbound files and data entry via keyboard at  the application level.
4. Ensure the encoding code works after the conversion at gateway or database level (if require).

Calcuation for Shipments’ Estimated vs Actual Delivery Dates

Customers like to get their shipments to reach the required destinations on time as to fulfill the customer satisfaction.  The calculation fo the estimated delivery dates/times varies on the user requirements and expectation to track each shipment milestone.

The works to do to get the calculation are:

• Understand the various shipment milestones and what are the end-to-end processes involved
• Indicate in each milestone what are the process and the event to trigger the milestones
• Calculate the turnover time to automate the calculation of  the actual event date/timestamp for each trigger event
• From the actual event, calculate the time difference (in hours) between the planned delivery and actual delivery timestamps to get the overall response time (part of key performance index metric).  This applies to all time differences to measure for the response time as per milestone.

System Specification Document for Warehouse Management System

In business computing, we understand that we need to capture and translate the business requirements into technical specifications in assist and understand what and how the proposed system is going to be designed.  Due to different solution for the different industries, the contents in a system specification document will vary but it should capture all the required information for the solution design.

For our warehouse management system we identify the following information to be captured into the system specification document:

1. System Architecture - A description of the network and hardware design for the solution.
2. System Design – A description of the system flow and integration with internal and external systems that includes communication protocols, formats and frequency.
3. System Process Flows – A collection of all the system process flows showing all the key points of system interaction and integration with internal and external systems.
4. Data Dictionary – Shows all the tables, primary and foreign key constraints, fields’ values, stored procedures and triggers that provides its propose and usage.
5. Message Mapping – A description of the mapping requirements between the message and the system.
6. Message Management – A description of the message execution and error handling within the system, includes staging tables, validation rules and error handling.
7. Screen Design and Execution – a description of the screen layout, field validation, database mapping/computation formula for each field and action upon clicking.
8. RF (Radio Frequency) Design Flow – a description of the RF flow and explanation of the logic including exception handling on each RF screen.
9. Reports – a description of all the reports required (operational and planning).  The details should include descriptions of all online reports, purpose/usage, intended audience, parameters and corresponding validations on screen, data extration source and logic, report format/layout and report export requirements.