Search less. Get more done.

No. Active collaboration, archives and content that is no longer needed can be handled separately. This reduces clutter and unclear sharing.

No. Content, responsibilities and publishing must be owned by the business units. We connect these requirements with the technical implementation.

Information should be easy to find and sharing easy to understand, and collaboration should work across teams too. We structure the intranet and document spaces, set up permissions and support the migration of existing content into the digital workplace.

Information architecture with areas, templates and owners Permission model for Teams, SharePoint and Confluence with groups from the directory Classification and encryption of confidential documents with Microsoft Purview or LAN Crypt Migration of file servers and legacy systems with cleanup and retention rules Governance with lifecycle for teams, sites and external sharing

Information architecture and permission model Operational intranet with templates Governance handbook with retention and sharing rules

We distinguish between binding company information, teamwork and personal drafts. Areas get owners, clear navigation and a procedure for outdated content. SharePoint, Teams or Confluence can take on different roles here. An intranet should provide answers to recurring questions; that is why we test search and navigation with typical tasks. More pages or a complete copy of the file server do not automatically make information easier to find.

An area is created, changes members and is eventually closed. We plan permission groups, external sharing and regular reviews for this. Particularly sensitive content needs suitable classification and protection measures; the specific technology is coordinated with how the content is used. During migration, we check metadata, versioning needs and existing sharing. Links in documents and embedded files are part of the testing, so that a technically successful move does not result in an unusable knowledge repository.

Acceptance testing includes sample tasks for employees, access checks and a test of the agreed publishing process. Editors receive templates and clear responsibilities. Technical operations and editorial maintenance remain separate tasks with named owners. Good starting points are your main information areas, existing file stores and your teams’ most common search problems.

Processes, system landscape, data quality Business units, IT, data protection, OTOKO® Process Consultant Process map, system inventory, data quality report, prioritized fields of action

Target processes, architecture, integration plan Business units, architecture, information security Target processes, system architecture, interface register, permission concept

One process or site in production OTOKO® consultants, key users, your IT Pilot with real data, feedback from key users, decision on rollout

Configuration, interfaces, migration, training OTOKO® consultants and developers, key users, your IT Configured system, interfaces, migrated data, training, acceptance

Monitoring, releases, support OTOKO® operations or your team Monitoring, release planning, support, annual permission review

Target processes, requirements, key user alignment

System architecture, interfaces, data ownership