Although I agree with Trevor that it is not supported, 'Classic' Sites will eventually be unsupported. But this is not the end of the world. With SPFx, Microsoft is either attempting to turn SP Admins into Devs or make SP Devs into Admins, its unclear as of now.
if you place this code snippet into a script editor webpart for a single page it works:
var myDOMgrp = document.getElementsByClassName("o365button");
/* Above: this creates an array of DOM elements
whose class attribute *contains* o365button
(there usually a lot of them on a given page) */
var myDOMitm = myDOMgrp;
/* Above: This selects the fifth DOM element
with the class name (which may be semi-unique to my tenant)
and one of a litany of reasons why it's not supported. */
myDOMitm.href = "https://Your URL Here";
/* Above: Assign a new value to the HREF attribute */
/** BONUS **/
/* Change the Text of the 'SharePoint' Link itself */
myDOMitm.innerHtml = "<span class='o365cs-nav-brandingText'>Site Name Here</span>";
Using Jquery gives a bit more flexibility in selectors, but requires jQuery to be injected into the page:
$('a[aria-label="Go to SharePoint"]').attr("href","https://Your URL Here");
/* Above: Smaller code footprint, more processor intensive,
requires jQuery to already be loaded */
The above solution works on a page-level.
My assumption is that you are currently using SP 'Classic' (not Modern) sites. If you don't know the difference, you have a lot of research to do about the future.
If you need to deploy across the tenant space, a different technique will need to be employed, and you probably have a lot more styling and customizing you will be required to deploy.
You can shoehorn custom JS code into every page of every 'classic site' By deploying the Enable-PNPResponsiveUI via powershell, after modification.