How would your support structure differ from the one shown here?
The support structure that we have in place is basically what you have shown, but it can be simplified in our case because the power user and the administrator are the same person (me) and we have yet to seek out custom tools.
I think you have a good start but if I may recommend, look at all of the possible failures that can impact PI. Some items can be fixed by a PI Power User or PI Administrator while others require IT support. Consider all of the firewalls, SSL certificates, SQL Servers, Kerberos delegation permissions, disk space, antivirus exclusions, etc. In medium to large corporations, different departments manage these items.
If you want a comprehensive model, I suggest starting with a list of all objects that can be created, edited, and disabled/deleted in PI and identifying who will manage each of those tasks. Next list all all dependencies that those PI services use like networks, firewalls, etc. and assign the various departments responsible for maintaining those services. In many cases, one team will attempt to diagnose the problem and escalate the incident to the proper group.
Don't forget about client tools, especially PI DataLink. Installation issues are very difficult to troubleshoot and the PI Administrator probably will not have administrative rights to everyone's computer to fix the problem.
In my experience, most of our tickets were reports of data flow interruptions (stale tags). Since we implemented High Available PI systems, many of those were actually passed to the SCADA teams because PI was not problem. Sensor failures, lost radio signals, or poor VSAT connections caused many problems for PI data.
I hope this helps.
Retrieving data ...