Skip to main content

What to Map Before Selecting Operational Technology

Operational Technology

What to Map Before Selecting Operational Technology

A practical framework for choosing mobile computers, scanners, printers, RFID, wireless infrastructure and other frontline technology.

F
Fusionware
8 min read
What to Map Before Selecting Operational Technology

Selecting operational technology often starts with a product question: Which device should we buy?

That may be the wrong place to begin.

A mobile computer, barcode scanner, RFID reader, printer or wireless access point can look ideal on a specification sheet and still perform poorly once it enters a real warehouse, manufacturing facility, healthcare environment or field operation.

The reason is simple: operational technology does not work in isolation. It operates inside a system of people, workflows, physical environments, networks, software, support processes and business requirements.

Before selecting the technology, map the environment in which the technology must succeed.

At Fusionware, we organize that assessment around seven areas: Workflow → Users → Environment → Devices → Connectivity → Systems → Support & Ownership

Here is what each one means.

1. Map the Workflow

Start with the work itself, not the hardware. Document what actually happens from beginning to end.

For a warehouse operation, that might include receiving, put-away, replenishment, picking, packing, staging and shipping. For field operations, the workflow may begin with dispatch and continue through arrival, identification, data capture, documentation and job completion.

Questions worth asking include:

  • Where does the workflow begin and end?
  • What information must be captured?
  • Where are delays occurring?
  • Where are errors introduced?
  • What requires manual entry?
  • Where do workers change devices or systems?
  • What happens when something fails?

This exercise often reveals that the original technology request addresses only one piece of a larger operational problem. A scanner problem, for example, may actually be a connectivity problem. A printing problem may originate in workflow design. A device-performance problem may be caused by an application or wireless environment.

Technology selection should follow workflow understanding, not precede it.

2. Map the Users

The same device can perform very differently depending on who uses it and how. Consider the people interacting with the technology throughout a normal shift.

Are they warehouse associates wearing gloves? Drivers moving between vehicles and customer locations? Healthcare workers who require frequent cleaning and disinfection? Technicians working outdoors? Supervisors who need both operational and administrative applications? Temporary or seasonal workers who require simple, intuitive workflows?

Important considerations include:

  • Frequency of use
  • One-handed versus two-handed operation
  • Glove requirements
  • Scanning distance
  • Screen visibility
  • Device weight
  • Ergonomics
  • Training requirements
  • Shift duration
  • Shared versus individually assigned devices

A technically powerful device that creates unnecessary friction for the user can reduce productivity rather than improve it. The objective is not simply to select capable technology. It is to select technology that fits the people doing the work.

3. Map the Physical Environment

Operational environments are rarely gentle. Temperature, dust, moisture, vibration, concrete floors, vehicle use, cleaning chemicals and physical distance can all influence technology decisions.

Before selecting equipment, understand where it will operate. Questions may include:

  • Is the environment indoors, outdoors or both?
  • What are the operating temperatures?
  • Are devices exposed to dust, water or chemicals?
  • How frequently are devices dropped?
  • Are workers moving between temperature zones?
  • How far away are the barcodes or assets being scanned?
  • Are devices mounted in vehicles or forklifts?
  • Are charging locations readily available?
  • Are there hazardous or regulated areas requiring specialized equipment?

These conditions affect decisions involving ruggedization, ingress protection, screen technology, scanning engines, batteries, mounting systems, cases and accessories. Environmental requirements should be documented before products are compared.

4. Map the Device Ecosystem

Avoid evaluating a device as a standalone object. Most operational devices become part of a larger ecosystem.

A mobile computer may require:

  • Batteries
  • Charging cradles
  • Vehicle mounts
  • Protective accessories
  • Scanners
  • Printers
  • Cables
  • Power supplies
  • Spare pools
  • Device-management software

The important question becomes: What complete configuration is required for this workflow?

This becomes especially important when organizations operate across multiple facilities. Without standards, individual locations can gradually acquire different models, accessories, chargers and configurations for essentially the same job. That increases support complexity and makes replacement planning more difficult.

Where practical, establish approved configurations by workflow or role rather than allowing each purchase to become a new technology decision.

5. Map Connectivity

A high-performance mobile device connected to an unreliable network is still an unreliable operational solution. Connectivity therefore deserves its own assessment.

Map:

  • Wi-Fi coverage
  • Cellular requirements
  • Roaming behavior
  • Dead zones
  • Outdoor coverage
  • Bandwidth requirements
  • Device density
  • Application response requirements
  • Remote locations
  • Redundancy requirements

Also consider what happens when connectivity disappears. Can the workflow continue temporarily? Does the application require a constant connection? Will transactions synchronize when service returns?

For geographically distributed operations, connectivity may involve combinations of enterprise Wi-Fi, cellular networks and other infrastructure. Do not assume that an existing network is adequate simply because laptops and phones appear to work. Operational devices may have very different roaming, latency and coverage requirements.

6. Map the Systems the Technology Must Support

Hardware rarely creates business value by itself. It enables the applications and information systems behind the workflow.

Identify the systems involved before finalizing hardware. These may include:

  • Warehouse management systems
  • Enterprise resource planning systems
  • Transportation management systems
  • Electronic health record systems
  • Asset-management platforms
  • Inventory systems
  • Mobile applications
  • Device-management platforms
  • RFID software
  • Identity and security systems

Then determine what the device or infrastructure must support. Operating system requirements, application compatibility, security policies, browser requirements, peripherals and integration constraints can eliminate otherwise attractive products from consideration.

This is one reason technology decisions made exclusively from product specifications can create expensive surprises later.

7. Map Support, Lifecycle and Ownership

One of the most overlooked questions in operational technology is: Who owns what happens after deployment?

Technology eventually requires support. Devices break. Batteries degrade. Employees leave with equipment in lockers. Operating systems change. Applications update. Facilities open and close. Models reach end of life.

Ask:

  • Who provisions new devices?
  • Who manages configurations?
  • Who handles repairs and warranties?
  • How are spare devices managed?
  • Who tracks assets?
  • How are replacements ordered?
  • How are retired devices removed?
  • Who maintains standards across locations?
  • Who evaluates replacement products when models change?

A successful deployment should have an operational owner, not simply a purchase order. This is especially important for organizations with multiple facilities or large device populations.

From Assessment to Technology Standard

Once these seven areas are mapped, product selection becomes considerably easier. Instead of asking, "What is the best mobile computer?" the organization can ask, "What mobile computer and configuration best support this specific workflow, user, environment, network and application?"

That is a much more useful question.

The next step is usually to establish an approved standard. For example:

  • Workflow: Warehouse picking
  • Device class: Rugged mobile computer
  • Scanning requirement: Standard and extended-range barcode capture
  • Connectivity: Enterprise Wi-Fi
  • Accessories: Protective boot and approved charging configuration
  • Management: Enterprise device-management platform
  • Support: Defined spare, repair and replacement process

The specific manufacturer and model should emerge from those requirements. Not the other way around.

Pilot Before Broad Deployment

For meaningful operational changes, a controlled demonstration or pilot can validate assumptions before a large rollout. A useful pilot should test the technology in the actual operating environment whenever possible.

Measure things that matter:

  • Workflow completion time
  • Scan performance
  • Connectivity
  • Battery performance
  • Application behavior
  • Ergonomics
  • User feedback
  • Failure conditions
  • Support requirements

The purpose of a pilot is not merely to prove that a device turns on. It is to determine whether the proposed configuration works reliably inside the actual operation.

The Goal: Fewer Technology Decisions, Not More

Organizations often accumulate technology one purchase at a time. One facility chooses one device. Another selects something different. Accessories multiply. Support becomes fragmented. Replacement purchasing becomes harder.

A better approach is to create repeatable standards around known workflows. That can turn future purchases from repeated technology evaluations into much simpler operational decisions: Which approved configuration does this location need, and how many?

That is easier for operations. It is easier for procurement. It is easier for IT. And it creates a more manageable technology environment over time.

How Fusionware Approaches Operational Technology

Fusionware helps established organizations assess, standardize, source, deploy and support operational technology across warehouse, manufacturing, healthcare, transportation and field environments.

Our approach starts with the workflow and operating environment before narrowing the technology. Depending on the requirement, that may involve technologies such as:

  • Enterprise mobile computing
  • Barcode scanning and data capture
  • RFID and asset visibility
  • Printing and labeling
  • Wireless and connectivity infrastructure
  • Mobile workstations
  • Device management
  • Accessories, charging and deployment infrastructure

Fusionware works across established enterprise technology ecosystems, including manufacturers and platforms such as Zebra Technologies, Honeywell, Cisco, SOTI, Xemelgo, Panasonic, Brother, Datalogic and Printronix.

The objective is not to introduce more technology. It is to establish the right operational technology, configured for the right environment, with clear ownership throughout its lifecycle.

Evaluating an Operational Technology Requirement?

If your organization is considering a new deployment, replacing aging equipment, standardizing technology across locations or trying to solve an operational problem involving frontline technology, start by defining the environment before selecting the product.

Fusionware's Solution Assessment is designed to help establish those requirements and determine the appropriate next step.

Request a Solution Assessment

Explore Topics

#operational technology#RFID#barcode scanning#rugged mobility#wireless infrastructure
F

Written by

Fusionware

Content creator and writer sharing insights and stories.