|
By Rebecca Gill, Technology Group International
Six Sigma is a highly structured process for problem identification and resolution. It is a discipline that involves reviewing potential problems, collecting appropriate facts, analyzing the known data, and identifying underlying root causes. It is focused on implementing appropriate solutions for known issues, but doing so in a methodical and well structured process.
A successful software selection project is no different. It involves identifying the known problems within an organization, collecting appropriate user facts or issues, and identifying the underlying root causes. In this case, the root cause would be the deficiencies within the current software package that are driving the organization’s operational inefficiencies.
Once these root causes are identified, the team can quickly move into corrective action mode. This involves compiling a list of must have requirements and identifying those software packages that include these critical points of functionality.
|
 |
If completed in a Six Sigma type of approach, emotion is removed from the software evaluation process. Glitzy ad campaigns and savvy salespeople no longer drive the process. The project team is in charge and they are operating in an educated and well planned manner. They are not only guaranteed solid ROI, they are guaranteed long-term success.
The Five Phases of Six Sigma
Six Sigma is focused on methodology and structure. Six Sigma is about identifying known issues, identifying the root cause, and taking corrective action. It is about proper planning and execution. Both are significant elements of any successful software evaluation and implementation project.
When looking at Six Sigma and the software evaluation process, the true tie resides in the five phases both projects possess.
Successful Six Sigma and system evaluation projects both consist of the following phases:
1. Problem Identification and Definition of Resolution Objectives
· Identifying the known operational problems and associated “pain points”
· Identify stakeholders such as internal and external customers
· Clarify project objectives
· Identify and document known constraints
2. Collect Facts and Measure Deficiencies
· Establish a project team and leader
· Create a project plan and create a budget
· Establish project controls
· Further identify known operational problems or areas of weakness
· Audit compliance requirements and list known compliance issues
· Review both internal and external stakeholder issues or complaints
3. Analyze and Identify Root Cause
· Create a functional requirements through root cause analysis
· Identify hardware and key vendor requirements
· Prioritize the list of requirements and prepare an RFP
· Create a short list of vendors
· Review a scripted demonstration of each vendor’s possible solution
· Objectively score each vendor in a consistent and planned manner
· Compare results and perform supplier reference checks
· Select the vendor
4. Improvement and Corrective Action
· Form an implementation team
· Create a project charter and a project plan
· Draft an implementation budget
· Export, cleanse, migrate, and test data
· Create an integrated test plan and execute
· Train implementation team and other applicable users
· Pilot system
· Go-live
5. Ongoing Control and Procedures
· Compare functionality and system output to original requirements list
· Measure user knowledge and train where necessary
· Measure system performance and optimize where necessary
· Validate compliance adherence
Problem Identification and Definition of Resolution Objectives
If a company has at all considered purchasing new software, there are plenty of problems or “pain points” readily available for identification. The important element of this first step is to initially investigate at a high level and then dig deeper during the next phase of root cause analysis.
One common issue with software selection projects is to forget major stakeholders because they exist outside of the company’s brick and mortar walls. Customer and vendors can be major stakeholders in any system evaluation and implementation project. Typically the demands of key customers, efficiency concerns with vendors, or governmental compliance issues lie high on the list of pain points. Identifying and addressing these concerns are critical for success.
Clarifying the overall project’s objectives must be done very early on in the process. Knowing the desired end result and staying focused on this will lead to a cohesive team and a project that ends on time and on budget. Allowing the team to veer off on side projects or allowing the team to get bogged down with unnecessary details will produce an unfocused team that loses track of the project’s key objectives and deliverables.
Identifying and documenting known constraints is crucial for staying on task and on target. Whether a company is limited by time, money, or internal resources, knowing, documenting, and living by these constraints will not only save time, it will save considerable frustration along the way for all parties involved.
Collect Facts and Measure Deficiencies
Investigating known problems and issues in an independent and impartial manner is difficult. If you are an integral part of the organization, staying neutral and focused may seem sometimes impossible. Structured project teams can manage this phase with success, although it is consuming of both time and resources. For this reason, many firms decide to obtain the assistance of external consultants who are independent in nature and highly objective. Just as the Six Sigma black belt is brought in, so is the independent consultant.
If hiring a technology based Six Sigma guru is not an option, finding the right tools to keep this phase structured is key for project survival. Remembering to focus on facts, measurable deficiencies, and desired results can keep the team on task. Utilizing a project plan with clearly defined requirements helps to keep both the team and software vendors focused.
Where manufacturing based Six Sigma projects focus on quality gaps and PPM’s or parts per million, the software based Six Sigma project focuses on functional requirements, hardware requirements, and key vendor questions. Focusing on the company needs and then relating these needs to possible supplier solutions will help the selection team objectively evaluate suppliers.
Analyze and Identify Root Cause
Reviewing known problems and deep diving into the root cause will provide a extensive list of must have functional requirements required for the new ERP package. Depending on the age of the existing system or magnitude of known gaps, the list may prove extensive. It is therefore important for the team to prioritize the list of requirements and prepare a thorough RFP is imperative. Doing so will allow the team to not only see their own functional gaps, it will help highlight the functional gaps between the various solutions and vendors.
Once a short list is identified and demonstrations scheduled, it is the black belt’s role to keep the software suppliers all in line with a scripted demonstration and sample data. This may seem easy, but by nature, software vendors are technically savvy creative people who want to show off their glitziest functionality, regardless if a company needs these functions or not. Keeping the suppliers on task during the demonstrations is one of the most an important parts of the entire evaluation process.
Finally, the team needs to objectively score each vendor in a consistent and planned manner, analyze the data, and compare the results. By this point the team should have a very good list of functional gaps and prioritized requirements. Do the reviewed software packages fill these gaps? Will they meet the project’s objectives?
Consider some basic questions when evaluating each supplier performance:
1. Did the demonstration follow the format or demo script provided?
2. Did the representative review all of the team’s must have functional items?
3. Can the package provide enough new functionality to effectively solve the gaps previously discovered?
4. Did the system appear easy to use?
5. Does the team feel the software can effectively operate the business?
6. Is the software significantly better than what the team is utilizing today?
7. Does the team feel the software can achieve the potential benefits listed in the ROI analysis and business case?
8. Did the team feel comfortable with the supplier representatives?
If the project plan was successfully followed up to this point, the team will know exactly what it is looking for in a package and a supplier and a clear cut winner will present itself. If the team has done poorly in previous tasks, the final analysis will prove difficult.
Improvement and Corrective Action
This stage of Six Sigma is about optimization. It is about implementing the corrective action discovered during the root cause analysis. Transferring this to a software evaluation project is no different. It equates to a solid, structured, and methodical implementation plan.
Implementing an ERP system is a project unto itself. The implementation team may be the same team as the original project team or it may have a shift in players. Regardless of the actual members, a solid implementation team must be formed and time allocated for their participation in executing the installation and implementation of the purchased software.
Once the team is formalized, a project charter and plan must be drafted and agreed upon. Typically this is done in a joint effort between the software supplier and in house project team. A realistic budget needs to be established to cover all necessary hardware, training, and related travel expenses. Although this may have been reviewed in the initial project planning portion of the software evaluation project, it needs to be discussed thoroughly with the software vendor to see if the budget is feasible.
One word of caution at this point is training and the expenses related to training. This is one area where many companies attempt to reduce costs, only to find the repercussions severe. Inadequate training is costly; much more costly than the initial training itself. A quality ERP system has thousands or screens and millions of lines of code. It requires a significant amount of training. Without training users are uncomfortable, confused, and not utilizing the functionality available within the package.
While training is occurring the team also needs to focus on the task of exporting existing data, cleansing this data, and importing it into the new system for testing. Remember this stage is about improvement, so cleansing the data is important. Typical legacy systems have years of data, entered in by multiple people, in multiple formats. Thus cleansing data prior to importing it is critical for true corrective action.
Also at this time, the team should be forming an integrated test plan that will be used for piloting the new system and any subsequent upgrades that occur in the future. An integrated test plan is a living document that needs to be reviewed, updated, and executed during implementation and again with each upgrade. Executing a number of pilots will provide a smooth go live experience and when done correctly, a positive go live experience as well.
Ongoing Control and Procedures
An ERP system and its ongoing usage is an evolution. Successful adoption is achieved through periodic and thorough self-evaluation which provides a means of reassessment throughout the system’s entire lifecycle.
Obtaining the full benefits of an ERP system, regardless of the ERP system at hand, requires an unending pursuit of continuous improvement. It requires a review of initial goals and milestones, an objective evaluation of the current state and a specific plan to close out any existing process or functional gaps. This gap analysis should occur shortly after go-live, a year after go-live, and any time a new software release or major corporate structural change occurs.
Conclusion
Six Sigma is a methodical approach to problem-solving. It is a process of identifying known issues, investigating gaps, analyzing data, designing alternate approaches, and then verifying that the corrective actions taken were in fact successful.
ERP is an ongoing pursuit to perfect operations and a never ending process of improvement.