Metataxis achieves new G-Cloud 13 accreditation for Cloud Support

Oct 2022 – Metataxis successfully achieves new G-Cloud 13 accreditation for Cloud Support

Metataxis is delighted to announce our successful application to become an accredited supplier on the new G-Cloud 13 Framework.

 G-Cloud 13 replaces G-Cloud 12, a valuable digital marketplace offering cloud hosting and software services, together with associated support services to UK central government departments and other public sector bodies.

Metataxis will now be recognised on this new Government framework as a Cloud Support supplier, enabling us to offer a variety of our cloud support services including cloud migration planning and deployment, security services, quality assurance and performance testing, as well as training and on-going support.

Comments Noeleen Schenk, Director at Metataxis, “G-Cloud is a secure method of procurement for public sector buyers looking for compliant solutions in this highly regulated arena. As a recognised supplier on the new G-Cloud 13 Framework, we are looking forward to supporting public sector organisations, including schools, local authorities and government departments across the UK, set up, maintain and ultimately get the most out of their cloud investments.”

Metataxis provides cloud support services and information management solutions, such as Microsoft 365 design, information governance, cloud migration and data privacy services, to over 250 clients in the public, private and third sectors.

If you would like to learn more about our cloud services, simply contact us.

20 years ago today, part 8: Strap on your jetpacks

This post is a continuation of a series of reminiscences and predictions on all things
information management, to celebrate 20 years of Metataxis. Let’s now look to the future…

Guessing what the future will hold is easy, guessing right is hard. What will IM look like twenty years from now? My first very unfashionable prediction is that whilst we will have fully AI-driven findability, metadata and folders will persist. They’ve been around for hundreds of years for good reason!

What’s involved in a SharePoint health check?

SharePoint Health Check

Many organisations think that Office 365/SharePoint deployment and configuration is both simple and quick only to find the reality quite different once the system is used in anger.  But a well-timed health check of SharePoint can save a lot a pain and stress down the road.

When to do a health check

A health check can be done at any stage of SharePoint implementation for many different purposes. For instance a health check may be done during a pilot or pathfinder exercise to check that the project is going in the right direction. Or the health check may be used for older implementations that may be experiencing issues for the purpose of root cause analysis.

It’s not just about the technology

The technical configuration of your Office 365/SharePoint system is important, but so too is how your information is organised within your implementation. Failing to understand your information management needs is often overlooked in Office 365/SharePoint deployments which can result in expensive, unusable, or even a failed system. We recommend any health check considers ongoing information management as well as the technical management.

What a health check should cover

With that in mind we recommend a SharePoint health check should consider both standard areas of functionality as well as information governance, management and strategies. The health check should consider the following aspects though depending on how SharePoint is configured may want more attention on some areas than others.

  • High-level Office 365 configuration
  • Site collection and site architecture
  • User permissions and user access model
  • Content types and columns
  • Term sets
  • Search configuration
  • Libraries, views and folder configuration
  • Navigation and high-level user interface
  • Usability and look and feel
  • Information governance and policies
  • Training and support
  • Culture and change management

Who should do the health check

Ideally a neutral third party should conduct a health check, so they can provide an independent and impartial assessment of the system. The third party may be a person or team within your organisation that has not been heavily involved in implementation. That internal resource would need to have the skills and expertise to complete a thorough health check. Alternatively external resource with the skills and experience may be contracted to do the work. The benefit of getting a health check from a skilled professional is assurance of quality of work as well as the ability to provide results quickly and accurately.

Metataxis SharePoint health checks

Metataxis can provide independent health check of your Microsoft 365 and/or SharePoint deployment to discover potential problems before they become actual problems. The Metataxis team has the unique skills and experience to bridge the world of technology and information management, to provide a unified and thorough analysis. Metataxis has a simple health check methodology that provides quick results. This is based on the many implementations we have worked on.

  • Analyse: A Metataxis consultant conducts an audit of your Office 365/SharePoint environment.
  • Document: The consultant documents their findings to produce an organisation specific set of recommendations.
  • Review: The consultant discusses the recommendations with the organisation, refining them as required.
  • Support: Follow-up advice is available via email or phone after the delivery of the recommendations.

We can scale any health check to the requirements of your organisation and point you in the right direction to give you the right information governance, architecture and strategy to help you on your way.  Get in touch with us today to talk using the contact form on the right.

Get stuck in! A six part series on big bucket retention. Part six.

Part six

Where the rubber hits the road: implementation

Retention implementation plan

During this series we’ve been looking at ways to simplify the retention schedule into bigger buckets. A retention schedule will usually take the form of a table which can then be applied to systems, and communicated to staff. The retention schedule may be supported by a written document, usually a retention policy or records policy which outlines governance, scope, roles, responsibilities, compliance expectations etc. The last piece of the puzzle is the implementation plan, which is the practical application of the retention schedule to records held in systems.

Document the practicalities

It’s inevitable when talking to stakeholders that they will flag up concerns about practical implementation of retention very early on. In fact they are likely to identify practical issues as reasons why longer retention periods should be applied to certain records. In an ideal world, these practical limitations should never dictate the retention period for a records class. Instead steps should be taken to improve the metadata, or improve the process so that new records can be managed appropriately and the legacy dealt with more strategically.

Adopt a risk-based approach

Because we work in complex environments it is necessary to have some kind of strategy to apply retention both to newly created records going forward and to records created in the past. This means having a good information architecture that supports retention management and a risk-based approach to the legacy records.

Leverage simple systems rules

This is just one element of planning for retention implementation. There are numerous practical considerations to take to get through the bulk of retention management. And yes, you guessed it, opportunities to lump things together in the implementation plan. For example, your retention schedule may have the following two rules:

  1. Financial management 7 years from end of financial year then delete
  2. Annual strategic planning 7 years from end of financial year then delete

The two classes stem from different functions, but require the same retention treatment. This means that a retention rule may be created in systems that says “delete content 7 years from end of financial year”. It will do the job for both classes, as long as disposal is done in line with the retention schedule (meaning also metadata is collected) it doesn’t matter what the technical mechanism. This is also helpful for more manual applications of retention where searches for eligible records are done for anything older than 7 years in relevant system areas for both functions.

Capture stakeholder intelligence

Finally, remember those tricky discussions with stakeholders where they provided masses of detail? An implementation plan is the perfect place to capture all that valuable intelligence. Not the retention schedule. Retention schedules need to be super-simple. 

Avoid complex rules

While there’s some scope to have lots of detail in a description field to help users identify the right retention period for their records, there’s not much room for nuance in your actual schedule. The more “ifs”, “ors” and “except fors” you have in the schedule the more complex your retention rules will have to be. Complexity costs. And frankly even your users will get confused by a schedule with too many caveats. Save these up for the implementation plan – it will be valuable intelligence for dealing with those legacy issues. 

And the plan is the thing that will make your retention schedule real!

So that’s the final entry of the series. I hope you have found it useful. If you want to know more about what implementation plans should look like or about retention in general, do get in touch using the contact form above or email info@metataxis.com.