The steps to success for your next control tower project
Nov. 18, 2015 - Large IT projects can present a seemingly endless array of complex and unexpected challenges, and that’s particularly true in the perplexing world of control tower projects.
By their very nature, control tower projects demand end-to-end visibility across the entire supply chain, with a crucial need to track massive amounts of data from an organization’s enterprise resource planning (ERP), master data systems, and web-based portals across diverse partners. And end-to-end visibility is only part of the challenge.
The value of the data produced relies on its ability to drive better and faster decision-making, while also providing a clear view of how those decisions impact the supply chain. Simply stated, once integrated, data must be put to functional use. This is where the real value lives. Data plus functionality equals success. Anything less, and the results could be worthless.
The need for data functionality cannot be overstated. This article will examine key challenges, as well as provide an understanding of what deployment teams can do to deliver results that meet expectations and generate high adoption rates.
What does the upfront data tell you?
Control tower projects typically involve months of developing data extracts in source systems before loading them into the application for data validation. In our experience, there is much to be gained through a rough-cut data load done quickly at the beginning, using manual file inputs.
A rough-cut data load indicates where data transformation will be required and exactly where this should occur — an ERP, data transformation layer, control tower application, or a revised business process. A rough-cut data load can also reveal upfront technical or design challenges while validating business processes.
Users generally do not fully understand what they need until they see the data in the system, so the effort during the data import to validate requirements and processes produces better results.
Revisit your approach to requirements gathering
In our experience, users seldom identify requirements well. Even when they do, their IT counterparts are not likely to perceive it all correctly.
In my own years of experience in IT and control tower solutions work, the sad truth is that I have never seen a requirements document that really nailed the assignment.
There needs to be a different approach, one that involves a higher level of expectation-setting. The idea is to assume the process is going to be wrong the first few times. So we say, “Let’s get the data, let’s do a prototype, and let’s test it.”
It is basically about working through iterations of getting it right, which is a shift in thinking from the traditional “big bang” IT deployment. It may seem painful at times, but overall, it gets you to a better product in less time. Here are a few guidelines:
• Keep requirements-gathering simple, and anticipate changes to the requirements and the use of the data,
• Understand the end-to-end business process before and after the control tower solution comes into place,
• Outline and understand overall objectives and key value drivers to ensure you are delivering a differentiating value from what the business uses today, and
• Play back prototypes to the business to validate gaps and further clarify.
Focus on what matters in data transformation
Data transformation is the key to usability. Without aligned data, there is no control tower. In more complex projects, this is the critical success factor, but too often it’s also the most difficult. You are typically gathering data from multiple sources and even from multiple entities — different plants, suppliers, vendors, and so on. One person’s “purchase order” is another person’s “sales order,” for example.
Unfortunately, data is often brought in and simply thrown into the functionality, creating confused users while increasing the risk that the project will be a miss. So it makes sense to dedicate time upfront to figure out the data.
Avoid making the leap into development too soon
Downsizing your design efforts and quickly jumping into development without understanding the end-to-end design point can be a problem on large projects. Unfortunately, prototyping often promotes a leap into development. But it is critical to use prototyping to define the end-to-end design point, focusing not only the functionality, but on how data is expected to flow through the system.
A key solution here is to keep large teams from operating in separate development silos. Each team member needs to understand what others are doing. You can really railroad each other by not understanding the end-to-end and not connecting the dots from a design standpoint. Yes, it can be difficult to achieve because it demands that everyone dedicates time to staying connected. But understanding the end-to-end vision upfront creates higher efficiencies and far better results.
Is your development cycle iterative?
From the development team’s point of view, the most disheartening part of a project can arrive when the business teams — after weeks or months of development — politely advise the development team that it’s completely missed the mark.
Many projects fail to deliver on intended benefits, and there is no doubt the approach to development plays a big role in success or failure. For that reason, you should consider the obvious benefits of adopting a more iterative development approach.
Iterative development involves breaking down tasks into smaller elements and then putting each one out in front of your business to assess it, validate it, and provide critical input. Keeping the business in the loop this way promotes far better development.
With an iterative approach, the developer’s work list is broken down into two-week sprints of effort, with continuous communication to business teams through playbacks. Playbacks are completed at 50 per cent, 70 per cent, and 100 per cent of development completion. This provides an invaluable opportunity to show business teams how things are coming together, and to validate that the solution is meeting requirements.
Improving adoption means not walking away too soon
Adoption is much harder than we realize. When asking diverse users to change processes and adopt new tools, we need to be there for them. Unfortunately, we tend to walk away too soon, saying, “We delivered the tool, now you can go ahead and run it.”
Adoption always takes longer than planned, and helping people through that process can dramatically improve the odds that your end product is fully adopted and driving value. The following steps can ensure successful adoption:
• Invest early in super users and key influencers who will promote the solution,
• Design the solution with the lowest-level end user in mind. It shouldn’t take a PhD to run an available-to-promise,
• Train at go-live and continue to train post go-live. Stabilization is always further away than you think, while staffing and role changes also demand ongoing support,
• Link the training material, employ local languages, and make it all easily accessible,
• Define metrics for adoption, then track and communicate them, and
• Manage expectations for when the expected value will be realized. A large-scale deployment takes about three months to start driving value and benefits. Unfortunately, organizations might look at the process in terms of weeks, rather than months.
There’s no guarantee that your next control tower project will be problem-free, but this guide should provide a payoff in terms of time, costs, overall results, and ultimately, adoption.
By Rebecca Schriver, Global Director, Supply Chain Solutions, Celestica
ABB Customer World
March 4-7, 2019
ATS Knowledge Day
March 28, 2019
Hannover Messe 2019
April 1-5, 2019
RFID Journal LIVE!
April 2-4, 2019
April 8-11, 2019
2019 Annual Valve Industry Knowledge Forum
April 9-11, 2019