A public institution should specify five things for a managed mobile fleet: who holds which devices and how they are owned, which apps each unit needs, how staff reach institutional services, where management data lives and who may administer it, and what evidence the supplier must show before contract-wide rollout. Otukan answers each of these in writing, per platform, and proves the answers on your own devices in a pilot. It manages Android and Apple phones and tablets through each platform’s own framework, and your institution keeps control of hosting location, administrator roles and supplier access.
Fleet needs
The specification should describe the fleet as it is used, unit by unit. Generic requirements produce generic answers.
| Question | Why it matters | What Otukan does with it |
|---|---|---|
| Who owns each device: the institution or the staff member? | Ownership decides which management mode each platform allows and what administrators may see | Maps each group to the matching enrolment mode on Android and on Apple devices |
| Which apps does each unit need? | Approved apps, in-house services and their settings drive app delivery | Builds an approved list per unit and delivers it through managed distribution |
| How do staff reach institutional services? | Network access, certificates and sign-in shape the policy baseline | Configures network profiles and device certificates per unit |
| Where and how are devices used? | Service desks, field work and shared handsets need different controls | Places counter and field devices in dedicated, task-locked operation |
| Which operating systems and models are in use? | Each platform and version has its own management capabilities | Confirms every workflow on your models and OS versions in the pilot |
Operational constraints belong here too: sites with poor connectivity, devices shared across shifts, and units that must keep working when the central service is unreachable. Otukan designs policy and dedicated-device behaviour around them.
Organisational structure matters as well. Ministries, directorates and regional offices often need their own administrators, their own policy variations and their own reporting, while a central team keeps oversight. Otukan mirrors that structure in device groups and role scopes, so each unit manages its own devices and the centre sees the whole fleet.
Control
Control requirements should be exact about what the institution decides and what it needs to see. Otukan meets them as follows.
- Hosting. The institution chooses where management data is hosted; Otukan maps the other places fleet data travels, including platform services.
- Administration. Administrator, help desk and auditor roles are held by institutional staff and scoped to units.
- Supplier access. Otukan support has no standing access and acts only on an approved, logged request.
- Audit. Administrator and support actions are recorded in a log institutional auditors can read and export.
- Exit. Export, deletion and device release at contract end are agreed before rollout.
A specification should avoid asking for locality it cannot verify. Stating that all traffic stays in one country, for example, conflicts with how Apple and Google platforms deliver management commands. Asking the supplier for a data-flow map per platform produces an answer that auditors can test. How Otukan handles data location, roles and supplier access in detail is covered on MDM data sovereignty.
Procurement
Good procurement asks for evidence, not assurances. Otukan supplies it in a form evaluators can check.
Platform coverage
Otukan answers per platform and per enrolment mode: what it supports on Android and on Apple devices, which management modes apply and which OS versions are confirmed. Android answers are never read across to Apple devices, or the reverse.
Migration evidence
Most institutions already manage some devices. Otukan provides a migration plan per device group, showing which devices need a reset, how policies and apps transfer, and the fallback for each wave. The approach is covered on MDM migration.
Acceptance
The contract-wide rollout follows a pilot on the institution’s own devices, with acceptance tests agreed in advance: devices enrol into the right unit, policy and apps arrive, remote actions complete, and audit entries appear. The questions worth asking every supplier are listed on the MDM requirements checklist.
Everything above runs on Otukan mobile device management, whose modules are listed on the product overview.