It's clear you do not understand the position. You need to read about what the job entails, and then decide if you want to accept the offer or not. It's a substantial change in role from your current position. In this case, the Wikipedia article is pretty accurate:
As others have stated, your primary responsibility is specification. To do this, you meet with stakeholders, and do projective business IT strategic planning.
While you can relatively easily negotiate for read only access as a demand from "on high", you should not personally use it. It should be used by your staff, temporary or permanent, for the performance of detailed specification compliance audits and spot checks. This is adequate justification to get management buy-in for this type of access. This type of access is for a role, not for a person. This is one of the reasons it should not be you.
For day to day operations, what you need are dashboards, which measure the degree of compliance with the detailed specification in an ongoing basis. The main purpose of the dashboards are to give you information you can summarize periodically to the executives, and as feedback into your strategy decisions going forward (particularly decisions surround capacity planning and technology adoption).
The purpose of the ability to audit is to ensure that the dashboards are not giving you fudged numbers based on what you want to hear, vs. what IT whats to implement (or what they can implement; you may be asking for the impossible, as a dictator, when you should be viewing the detailed specifications as a negotiation). Audits can also provide progress reporting on deployment of specification changes, based on what IT is reporting vs. actual. Since you appear to be planning a lot of churn for them, I suspect you will need one FTE staff member to perform rolling audits to ensure that things are on schedule, and if they aren't, you can negotiate either a schedule change, or a working emphasis (this is a prioritization list: other things will suffer if you have insufficient staff in IT for the demands being made).
Good examples of what you can dictate are things you've complained about: Automated Provisioning, use of SRM in VMWare installations, enabling automated tiering in EMC storage hardware, and so on. Things which will bite the enterprise on the ass eventually, if they are not done.
Your initial dashboards should be based on displaying progress on this (e.g. "percentage of VMWare installations with SRM enabled", etc.).
Note that before any of your shit starts running down hill, you need to make sure you are not downhill from them. To do that, you are likely going to have to have meetings, a couple times a week (usually something like Tuesday/Friday), to collect requirements for the business, and then mash it into part of the requirements document that you will need to prepare before you start defining strategy and dictating conformance/performance). Otherwise you will find yourself buried in crap, because your goals will not be clearly derived from the enterprise goals.
Your ability to take new input from the early in the week meeting and report it in the late in the week meeting with the stakeholding execs is going to be your main performance metric until you go into the design, then implementation phases. Your goal is to get to an ongoing maintenance/change phase. Your metrics will be different in each phase. You will use these in your performance reviews to justify yourself.
If you have other things you care about, they need to be in the specifications -- and they probably need a dashboard, and they need to have a schedule.
For example, if you care about automated provisioning, then you need to have a scratch machine that is identical to the production machines, and you need to have a metric of "how long from a zeroed state does it take to provision the machine and make it ready for service. You would likely break this down further by provisioning category, if all machines are not provisioned identically (it's unlikely that they will be), and you need to have a list of configurations that the dashboard uses to display per-configuration percentage above/below goal speed (translates to downtime), and so on.
Note that for every metric you define, you will need to be prepared to negotiate a baseline acceptability, and then provide feedback into the IT performance review process as well -- and be prepared to give out "exceeds expectations", if they happen to do so -- be fair, do not just be a dictatorial ass: these people are your partners, not your minions.
If after reading the definition of the job -- and reading all of the above -- you feel that you are prepared to take the job, and define at least a rough outline of the stages of getting the processes in place, and demonstrate your progress on doing so to the execs -- and you want the job -- then take it. Otherwise, decline the job, and expect them to either find a second choice from inside to promote. Most likely whoever else has kept their systems up, and also bitched to management about the difficulty in doing so due to the environment, an outside person who can do the job, an outside person who's basically going to be a NOOP, or, worst case, an outside person who thinks they can do the job, but who will actually screw everything up. In other words, you should also think carefully about whether or not you can afford the risks of not taking the job, even if it's not entirely to your liking or inside your comfort zone.
Hope that all helps.