Hi, Not sure I agree. And you kind of pointed it out later in your own email. Have most of your data global and any specific ones you can put when your SDs want to raise a ticket to themselves and keep the info within that company.
I always make the customer company a operating company as well. It doesn't matter that you wont have a support org or people but where it does add value is if the customer company needs a different change management / release model etc. All those module rules are based off the support company and not the customer. So all tickets that can have shared data be raised under the customer company (Which is an operating company too), and any tickets/data that is sensitive to the SD then they raise an internal ticket where the customer company is the SD company. Again, remember that the access permissions are based on the support user and not the company they belong to on the General tab of people. This is just really who pays their salary / HR perspective etc. My best advice is to create example companies and data and have a play. Write up some use cases and see which works for you. Good luck Kind regards Danny -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Schon, Stuart Sent: 01 September 2011 04:33 To: arslist@ARSLIST.ORG Subject: Re: Multi-tenancy Setup for ‘One Customer – Multiple Support Desks’ scenario Hi You will have an issue with the 3 Support Companies, 1 customer model as the Ops/Prod cats are normally associated with the customer coy not the support coy. You really have two choices. Lots of 'duplicates' or consolidate your list to fit all 3 support companies needs. I would pump for the latter. Op Cats should be fairly generic and does it really matter that some prod cat products are visible to all as you are all in the same company. If you don't want a lot of clutter then make the op cats and prod cats global. All the people would in the customer coy so that’s not a problem The support groups will not be a problem as they will be assigned to the relevant support coy. ..... you will need to develop some rules (some additional very simply development may be required) to ensure that the correct ownership is associated with the ticket. We operate multiple companies and multiple SD's but none of the companies each SD's support overlap. Ownership is the key to allow the right SD overarching access to the ticket so they can reassign when needed. Stuart Schon Team Leader Fujitsu Australia Limited 2 Julius Avenue, North Ryde NSW 2113, Australia T +61 2 9113 9435 M +61 458 592 245 stuart.sc...@au.fujitsu.com au.fujitsu.com Please consider the environment before printing this email -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of strauss Sent: Thursday, 1 September 2011 04:48 To: arslist@ARSLIST.ORG Subject: Re: Multi-tenancy Setup for ‘One Customer – Multiple Support Desks’ scenario You are welcome to look at the multi-tenancy model documented on our web site, which is way more complicated than your requirement. One thing to remember is that if all of the customers are in one customer company, and all three service desks' support staff members (homed in three separate operational companies) are given access to that customer company, they will be able to search/find/see but not edit incidents etc., that are created for those customers but assigned to the other service desks, because Company will effectively provide universal access. The tickets will not appear in the consoles of groups they are not assigned to, unless you start mixing up Ownership (which 7.6.04 handles very badly compared to 7.0). You may want to set rules to make owner same as assigned - it may default to that, but we have very explicit rules for ownership and almost never see other behavior. In our implementation, the only way that a ticket is restricted to a single operational company is if the support staff member uses a support staff ID in that company as the customer, and it remains owned and assigned within that same operational company. Christopher Strauss, Ph.D. Call Tracking Administration Manager University of North Texas Computing & IT Center http://itsm.unt.edu/ -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of RamaKanth Sent: Wednesday, August 31, 2011 10:34 AM To: arslist@ARSLIST.ORG Subject: Multi-tenancy Setup for ‘One Customer – Multiple Support Desks’ scenario Dear Community, We are having difficulty in implementing Multi-tenancy model with the below setup we have. Any thoughts on implementing this are highly appreciated. We are part of one company (lets call it as ‘ABC’) We have 3 different service desks 1. IT Service Desk 2. Finance Service Desk 3. Facilities Service Desk How do we manage foundation data to have this managed in this multi-tenancy setup? We want the Transactional Data (such as Helpdesk, Problem… data) to have access to their service desks alone. The Support Groups and Operational Categorizations are different for each service desk. The people, Organization, Location information is same for all the 3 desks. Customizing will be the last option to be implemented. Went through all the multi-tenancy documents provided by BMC but not able to fit our requirement properly. BMC Multi-tenancy model is defined for ‘One support desk – Multiple Customers’ model, but our requirement is otherway round ‘One Customer – Multiple Service Desks’ Thank you. Rk _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are" _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are" _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are" _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"
