 |
 
|
 |
|
| Main Site > Europe Channel > Methodologies > Process Management | Search: | for |
|
|
|
|
|
IT Development: Finding Balance Between Business and IT
By Jean-Francois Guilland and Arne Buthmann A discussion about an ideal IT system often centers on user friendliness, system reliability, and implementation on time and on budget. These discussions should also include how to create more business value through the development of systems following a disciplined, fact based approach with a clear customer focus. For example, consider a telecom provider who wanted to reduce the cycle time of the repair process. Call center agents received calls from customers and forwarded problem descriptions to the field service agents who then solved the problems. Management identified inefficiencies at the call center – operators spent too much time conversing with clients, with some calls lasting more than 10 minutes. Management implemented a new IT system that kept track of calls and alerted operators when they approached the system-wide goal of six minutes. If operators met their goal of reducing the time per call, they received a bonus. After two months, the bonuses for operators increased sharply. Executives, however, were astonished to see the cycle time of the average repair also increased. Why Did the Cycle Time Increase?Managers invested in IT to improve the process, yet the process worsened, as shown in Figure 1.
When management consulted the repair manager, he explained that the repair time increased because information previously collected at the call center was no longer available to the repairmen. The repairmen called the customers themselves to get the necessary information, adding an additional 15 minutes to each job. The IT project was implemented from purely a functional perspective, and no thought was given to how it might affect other aspects of the organization such as repair times. Management should have done an end-to-end process view, and included all stakeholders. If that had been done, the customer services manager could have shared the importance of the call center gathering all information. Avoid Isolated Process ChangesManagement could have avoided the problem if they had used a bit more common sense, process orientation and cross-functional thinking to understand how lowering the quality performance of the call center agents might impact the field service activities. Process orientation and cross-functional thinking would have ensured the key performance indicators (KPIs) for the call center were better aligned between the two teams. Use a Methodology to Focus on IT and BusinessUsing a methodology could help prevent management from focusing solely on IT solutions and assist them in sustaining their business focus. The first step is to identify the problem. Many IT systems are a technical success but an organizational failure. A workable methodology must guide the organization in making the best decision on whether the problem being solved is the correct problem. In this case, the higher-level problem was that the overall repair times were too long. The decision, however, to focus on the call time was made too quickly and with a limited view. A more solid root cause analysis of the problem and a better understanding of drivers of long versus short repair times may have revealed a more comprehensive picture. At a minimum, such analysis would have shown that the quality of the collected customer data has a significant impact on the overall repair time and should not be compromised. Second, assuming that the right problem is being solved, a quality solution must be created following a well-defined phased and rigorous approach (i.e., a systems development life cycle). This solution is then passed to the customers. In this case, the drivers of long repair cycle times were missing information. Call center agents spent a lot of time on the phone with the customers and often did not know what information to collect. In a later stage of this project, an optimized data entry record was created that guided the right questions (and only these questions) and ensured that important information was not missed. Additionally, a frequently asked questions (FAQ) database was installed to help call center agents solve specific problems on the phone without involving the field service. Third, assess the impact of the solution in the field and provide a way of closing the loop with the original proposal. Follow through and measure the actual benefits, so that project managers can have a true measure of the value to the organization. In this case, KPIs were now defined for both the overall repair cycle time and the first call resolution rate. These KPIs were tracked with a dashboard after the project’s closure and reflected good performance results for the call center agents and the field service. Integrate Design for Six Sigma (DFSS) and System Development Life Cycle (SDLC)Integrating the DFSS roadmap in the system development methodology can strengthen the business focus of IT system delivery. The following steps describe the generic system development process:
As Figure 2 shows, these steps can be easily aligned with the identify, design, optimize, validate (IDOV) roadmap. If a company wants to get the full benefit of DFSS, however, it is important to bridge the gap between business and IT with additional steps at the beginning and the end of the system development cycle. DFSS will then support the better understanding of the business process and the customer requirements involved, and allow the organization to realize proven business results as well as continuously monitor process metrics.
Adoption of DFSS ToolsDFSS tools drive a stronger alignment between IT and business and should be integrated in any existing software development roadmap:
Tollgate review (checkpoints and checklists) is an important DFSS stage that helps move between project phases. Here, the sponsors and steering committee are actively involved in deciding whether the project should proceed to the next stage and recommend corrective action where needed. For example, the phase review at the end of “identify” might discover that the right problem is not being solved. The project can be terminated or re-scoped, saving valuable resources. Figure 3 shows where in the IDOV roadmap selected DFSS and SDLC tools can be integrated. Which deliverables should be integrated in a businesses SDLC methodology depends on the business and its IT needs and must be carefully determined.
Paradigm Shift Through DFSS and SDLC IntegrationIntegrating DFSS and SDLC will bring a paradigm shift within IT in three ways:
Reproduction Without Permission Is Strictly Prohibited – Copyright Requests Publish an Article: Do you have a Six Sigma tip, learning or case study? Share it with the largest community of Six Sigma professionals, and be recognized by your peers. It's a great way to promote your expertise and/or build your resume. Read more about submitting an article.
|
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|
| Home | Discussion Forum | Event Calendar | Job Shop | |
 | |
| Link To iSixSigma | Rate This Page | Report A Problem | Free Content For Your Site | Submit Article For Publishing | |
| |
| Terms of Service. �2000-2009 iSixSigma. All rights reserved. v3.0lb, 0.2 |
About iSixSigma � Contact Us � Privacy Policy � Site Map. |
