Mauricio: I'm not sure how you're defining "large", but in our enterprise we have around 10,000 employees across two main sites and several smaller satellite locations.
In terms of our Remedy support, we have a single team with people who do everything you mention, including custom Remedy apps. Our team members are considered to be Tier 1 - 3, similar to how Support Groups define themselves, more or less as follows: Tier 3 - advanced troubleshooting, tuning, mid-tier management, interaction with DB, network & server teams, monitoring users, controlling licenses, data migrations Tier 2 - custom Remedy apps, Kinetic Surveys and Service Requests, foundation data requests, *testing Tier 1 - reporting, adding, deleting or modifying users, roles, permissions, basic application troubleshooting, monitoring incoming requests and assigning them appropriately. We additionally have a person who serves as our team leader and whose work is a combination of project management and Tier 3 support (he's basically our Tier 3 backup.) Most of our developers are considered Tier 2 and can back each other or our Tier 1 person up as needed. We have a couple of Tier 2s who were hired specifically to work on a subset of our custom apps, though both of them helped with our ITSM implementation, and if we have a customer who is willing to fund a Tier 2 full-time, that person can be sucked into that project for however long the customer is willing to pay. *An exception at Tier 2 is testing, which is my only responsibility and which the other Tier 2s don't do aside from what a developer would do normally. I like to say that I'm the harmony to the rest of my team's melody. I'm not sure there's a "best way" or a "right way" to run your Remedy team, just a way that makes sense for how your organization works and how much support you have from management, and that's most likely going to be different in different places. I would just say there are advantages to being one big team because often what one person does, particularly at Tier 3, impacts the rest of us. Plus we've been able to streamline how some of our requests get worked owing to knowing what requests the others are actively working on. Hope that helps! Natalie Stroud SAIC @ Sandia National Laboratories ARS-ITSM Tester Albuquerque, NM USA [email protected]<mailto:[email protected]> ITSM 7.6.04 SP2 - Windows 2003 - SQL Server 2008 From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of Mauricio M. Sent: Monday, October 08, 2012 10:38 AM To: [email protected] Subject: [EXTERNAL] Thoughts on Remedy administration ** Hello, I wonder if anyone can share any experience or recommendations on how do you organize your Remedy administration team, specially in large companies, since I believe there has too be at least two teams, one team focused on the technical side of Remedy and its related infrastructure, mosty having to do with troubleshooting, tuning, interaction with OS, DB, network teams, etc., and then there is the other team focused on the tool administration tasks such as monitoring users, controlling licenses, adding, deleting or modifying users, roles, permissions, ITSM foundation data, etc. If you customize or develop apps in Remedy there would be maybe a third team Thank you and Best Regards, -Mauricio _attend WWRUG12 www.wwrug.com<http://www.wwrug.com> ARSlist: "Where the Answers Are"_ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"
