Implementation concerns often delay decisions longer than they should.
"What's the process actually like? How disruptive will it be? How long before we see results?"
These questions deserve clear answers. This article walks through typical implementation phases, training considerations, common challenges, and success factors—so you know what to expect before you begin.
Is This a New Implementation or Expansion?
"Are we looking into starting a new system implementation or is this adding to an existing system?"
That's usually the first question. The answer shapes the entire approach.
New implementation means building from scratch: defining scope, mapping stations, establishing call types, configuring escalation paths, and training everyone for the first time.
Expansion builds on existing infrastructure: adding buttons to new areas, onboarding additional responders, or extending coverage to new shifts or buildings.
Sometimes the best answer is neither:
"Is it better to start fresh or not? I mean, it's been at least six years."
Legacy systems may not be worth upgrading. If the existing technology is outdated or the configuration has drifted from current needs, starting fresh can be cleaner than retrofitting.
Typical Implementation Phases
Most Andon implementations follow five phases, though the timeline and depth of each varies by scope and complexity.
Phase 1: Planning and Requirements
Before any equipment arrives, define what you're implementing:
Scope: Which areas, lines, or stations will be covered? Start focused—you can always expand.
Call types: What kinds of support will operators request? Common categories include maintenance, materials, quality, and supervision.
Responders: Who will receive each call type? How will escalation work?
Network requirements: Will the system connect to your network for dashboard access? This affects IT involvement.
Timeline: When does this need to be operational?
"System's setup within 9 months; implementation must align with this timeline."
Clear timeline expectations help ensure resources are available and dependencies are managed.
Phase 2: Configuration
With requirements defined, the system gets configured.
"So if we were to get these from you guys, you guys would configure it on the direction that I would give, correct? Initially. Yup. But any changes after that we're free to make on our own?"
Most vendors offer pre-configuration:
"The customer wants the system to be pre-configured before it is sent to their location."
Pre-configured systems arrive ready to install. Buttons are programmed, pagers are assigned, escalation sequences are set. You plug in and test rather than building from scratch.
Configuration decisions include:
- Button labels (what message does each button send?)
- Responder assignments (who gets each call type?)
- Escalation timing (how long before backup is notified?)
- Dashboard layouts (what information appears where?)
Phase 3: Pilot Program
Starting with a pilot is strongly recommended.
A pilot tests the system in a limited area—one line, one department, one shift—before full rollout. This approach:
Validates assumptions. Are buttons in the right places? Are escalation times appropriate? Does the dashboard show what people need?
Builds confidence. Success in the pilot area creates advocates for broader rollout.
Identifies issues early. Better to discover problems with 5 buttons than 50.
Generates data. Even a short pilot produces response time data that demonstrates value.
Typical pilot duration is 2-4 weeks. Long enough to see patterns, short enough to maintain momentum.
Phase 4: Rollout
After a successful pilot, expand to additional areas.
Rollout strategies vary:
By area: Add one production line or department at a time.
By shift: Start with day shift, then extend to evenings and nights.
By call type: Begin with maintenance calls, then add quality and materials.
The key principle: don't rush. Each expansion should build on lessons from the previous phase. Quality of implementation matters more than speed.
Phase 5: Optimization
Implementation doesn't end at rollout.
"We can also reconfigure this system for you... if you still want to make modifications, you could remote into the computer to do so."
Once the system is running, data reveals opportunities:
- Response times that suggest escalation adjustments
- Call patterns that indicate staffing gaps
- Stations with unusually high or low call volume
Pre-Implementation Planning Checklist
Before implementation begins, ensure you can answer these questions:
Scope and Coverage
- [ ] Which areas/stations will be included?
- [ ] How many call buttons are needed?
- [ ] Where will buttons be physically mounted?
- [ ] What call types will operators use?
- [ ] Who responds to each call type?
- [ ] What are the escalation rules?
- [ ] Where will the transmitter be located?
- [ ] Is network connectivity needed for dashboards?
- [ ] Are there IT requirements or approvals needed?
- [ ] Who owns the implementation project?
- [ ] Who will be trained?
- [ ] How will success be measured?
- [ ] When does the system need to be operational?
- [ ] Are there dependencies (facility changes, hiring, etc.)?
- [ ] What's the pilot timeline vs. full rollout?
Training Considerations
Andon systems are designed to be simple. Training requirements reflect this.
Operator Training
Operators need to know:
- Which button to press for which situation
- That pressing a button ensures someone will respond
- How to indicate when help has arrived (if using acknowledge buttons)
Responder Training
Responders need to know:
- How to read their pager or watch
- How to acknowledge calls
- What happens if they don't respond (escalation)
- How to close calls when complete
Supervisor Training
Supervisors typically need deeper knowledge:
- Reading and interpreting dashboards
- Reviewing reports and identifying patterns
- Making configuration changes
Self-service configuration capability means supervisors can adjust button labels, escalation timing, and responder assignments without vendor involvement. This training takes 30-60 minutes.
Change Management
Technology implementation is also a people change. Effective change management addresses:
Communicate the "Why"
Operators and responders should understand why the system is being implemented—and what's in it for them. "Management wants to track us" creates resistance. "You'll get faster help when you need it" creates support.
Address Concerns Proactively
Common concerns include:
- "Will this be used to punish me?" (No—it's about ensuring response, not surveillance)
- "Another system to learn?" (It's simpler than what you use now)
- "What if it doesn't work?" (That's why we're piloting first)
Involve Operators in Planning
The people who will use the system every day have valuable input on button placement, call types, and workflows. Involvement creates ownership.
Celebrate Early Wins
When the pilot shows reduced response times or catches a problem faster, communicate it. Success stories build momentum.
Respond to Feedback
If operators report issues—buttons in wrong locations, confusing labels, escalation too aggressive—address them promptly. Responsiveness builds trust.
Common Implementation Challenges
Challenge 1: Scope Creep
"If you wanted to expand at any point in time, you can do so."
That flexibility is valuable, but it can lead to scope creep during initial implementation. Adding "just one more area" repeatedly delays go-live.
Solution: Define initial scope clearly. Document future expansion plans separately. Launch the defined scope, then evaluate expansion.
Challenge 2: IT Integration
"I'm probably going to need IT here to help me out."
Network connectivity for dashboards often requires IT involvement. If IT isn't engaged early, this can become a bottleneck.
Solution: Identify IT requirements during planning. Most Andon systems have minimal network needs, but early communication prevents surprises.
Challenge 3: Resistance to Change
"We've always done it this way."
Some operators or responders may resist the new system, especially if they perceive it as surveillance or extra work.
Solution: Focus communication on benefits (faster help, less walking, fair accountability). Let pilot results demonstrate value. Address concerns directly rather than dismissing them.
Challenge 4: Configuration Paralysis
Trying to design the perfect configuration before launching leads to delays. "What if we need to change it later?" becomes a reason not to start.
Solution: Accept that initial configuration will evolve. Modern systems are designed for easy modification. Launch with a good-enough configuration, then refine based on real data.
Success Factors
Implementations that succeed share common characteristics:
Executive sponsorship. Someone with authority champions the project and removes obstacles.
Clear ownership. One person is accountable for implementation success.
Pilot before full rollout. Test in a limited area before expanding.
Measure and communicate results. Data demonstrates value and builds support.
Iterate based on data. Use response time reports to continuously improve.
Frequently Asked Questions
How long does implementation take?
Pilot implementations can be operational within days of equipment arrival. Full rollout timelines vary with scope—a single department might be weeks; an entire facility might be months. Pre-configuration reduces on-site time significantly.
Do we need IT involvement?
Only if you want network-connected dashboards. The core system (buttons, pagers, transmitter) operates independently. Dashboard access requires network connectivity, which typically involves IT.
Can we change configuration ourselves?
Yes. Modern systems provide administrative interfaces for changing button labels, escalation rules, and responder assignments. Initial configuration is often done by the vendor; ongoing changes are self-service.
What if the pilot doesn't go well?
Pilots surface issues—that's their purpose. If the pilot reveals problems, address them before rollout. Button placement wrong? Move them. Escalation timing off? Adjust it. Few pilot issues are fatal; most are configuration refinements.
Getting Started
Implementation is more straightforward than many expect. The technology is mature. The process is well-understood. The risks are manageable with proper planning and piloting.
The harder question isn't "can we implement this?" but "are we ready to act on what the data reveals?"
Related reading: