Norm, I would submit that installing "a custom built Remedy app" and creating such an app for sale is two ENTIRELY different things. I'm sure that on a one off basis you can get the kind of cooperation you are talking about here (let's say you can do it 10, 20, even 30 times, but can you do it 100, 200, 1000?). However, when you are attempting to sell a product (and stay and business and make money, blah blah blah), telling the customer that their only choice for people data is through active directory, and their data must look like this and these attributes must be populated, that your opportunities for staying in such business would be severely limited.
Scott Parrish IT Prophets, LLC Original Message: ----------------- From: Kaiser Norm E CIV USAF 96 CS/SCCE [EMAIL PROTECTED] Date: Tue, 8 May 2007 10:46:47 -0500 To: [email protected] Subject: Re: Why Import People into ITSM 7 at All? OK, but back up. Let's say you're a Remedy consultant and you've arrived at a site to install a custom built Remedy app. You ask, "Is your AD data any good?" and the customer hems and haws. Stop right there. What do you do now? The point is, the customer data MUST COME FROM SOMEWHERE! You say, the only thing worse than having bad data in one data source is having it in two data sources...fair enough. But where does your initial customer data come from in the picture I just painted? Are you going to key it in by hand? If the answer is yes, then why key it into Remedy and not into the AD instead? Here's what I've done several times in the past. The initial setup is very painful, but from there forward it's mostly smooth sailing. I arrive onsite to do an install. I ask, "Is your AD data any good?" and the customer answers, "Not really." I immediately say, "OK, well, we need to make it good. Otherwise tickets will be misrouted and you won't be able to contact the people identified on tickets." The customer then invariably says, "Yeah, but that's A LOT of work." I say, "I understand. Just trust me." We begin pounding the keyboard, populating AD, not Remedy. When we're satisfied the data is good, we turn on the Remedy solution. The Remedy solution pulls customer data from AD. But it doesn't stop there. Not only does Remedy PULL, but it PUSHES, too. So for instance, a customer calls the company's Help Desk to report a problem with e-mail. The HD analyst says, "Sir, let me verify your personal info. Is your phone number still 888-1234?" If the customer says, "No, I moved offices. It's 888-4321." The HD analyst makes the change, clicks an UPDATE AD button, and voila! The AD is updated on the spot, on-the-fly. Now let's say the same customer calls ten minutes later. A different HD analyst helps him this time. He pulls the customer up, and lo and behold the phone number for the customer is correct! Consequently, since the data systems are now tightly integrated, the AD data is effectively policed and kept more "up to snuff" organically. We even have a customer self-service portal where the customer can submit his/her own ticket. While there, the customer can also UPDATE THEIR OWN AD INFO (phone number, room number, organization, title, building number, etc.)! The consequence? It's win-win. No extra data in the Remedy database and the AD is kept more current because the customer and the HD have a direct link to it. -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Rick Cook Sent: Tuesday, May 08, 2007 10:26 AM To: [email protected] Subject: Re: Why Import People into ITSM 7 at All? Quite true, Scott. In addition, the way companies use AD data, and the degree of data integrity contained therein, also varies greatly from place to place. When asked about integrating AD with Remedy, the first question I ask is "How reliable is that data"? I very often get hemming and hawing, at which time I remind them that what's worse than having bad data in one place is having it in TWO places, and that they will need to have ONE reliable data source for people data, or risk not being able to identify and/or find the people they're supposed to be helping. If they cannot depend on whoever is supposed to keep the AD data up to date and accurate, they may want to consider the ramifications of using Remedy as that trusted source of user data. That's not optimal, of course, but sometimes the practical must trump the desirable. Rick -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Tuesday, May 08, 2007 8:19 AM To: [email protected] Subject: Re: Why Import People into ITSM 7 at All? I think the issue boils down to the fact that not all Active Directory structures are POPULATED equally. It's been my experience that beyond First Name, Last Name, Email Address and Phone number that the way what could be considered "standard attributes" are populated varies greatly across organizations. Scott Parrish IT Prophets, LLC Original Message: ----------------- From: Jason Miller [EMAIL PROTECTED] Date: Tue, 8 May 2007 08:02:36 -0700 To: [email protected] Subject: Re: Why Import People into ITSM 7 at All? Hi Norm, I don't think there was probably much of a decision when Remedy (pre BMC and Peregrine) started storing people data in the database. That was in a time when authoritative directories were not quite as standard. Now looking forward. My first thought was that as not all companies may have an authoritative directory (or one dependable/clean enough to use) and thus they need to include a place to store people. But then also thought about the number of free directory servers (MS ADAM, Sun One) that could be used (or even bundled with ARS?) to hold the people data if there wasn't and LDAP source to connect to. But now you have another product to support, patch and a possible security issue if you don't have somebody knowledgeable with directories. So is BMC in a position to force a company to have a directory server? Now it would be really cool to have an option upon install to use/install a directory server or import the people workflow but can you imagine how complicated the install and workflow could get? Jason From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Kaiser Norm E CIV USAF 96 CS/SCCE Sent: Tuesday, May 08, 2007 7:00 AM To: [email protected] Subject: Re: Why Import People into ITSM 7 at All? ** Rick: Yeah, don't get me wrong-I'm certainly not criticizing those of us out there who choose not to untangle the mass of spaghetti in ITSM 7 as far a people data goes. In fact, even if you had the time I'd recommend not doing it because it deviates so drastically from the OOTB design and code. I'm questioning BMC's decision to go that way in the first place. _____ From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Rick Cook Sent: Tuesday, May 08, 2007 8:52 AM To: [email protected] Subject: Re: Why Import People into ITSM 7 at All? I see what you're saying, Norm, and in a theoretical sense, I agree. However, ITSM 7 is both very complicated and new enough that knowing what existing workflow to untangle to draw the data directly from AD would take more time than most of us have. So in the absence of a viable option of having two data sources, I will settle for the second best outcome - that of not having to maintain two duplicate data sources. The AD data that is actually useful will be maintained only there, and copied to Remedy. The rest, which is mainly better off in Remedy anyway (i.e. Group permissions, etc.) will be maintained in Remedy. Rick _____ From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Kaiser Norm E CIV USAF 96 CS/SCCE Sent: Tuesday, May 08, 2007 5:54 AM To: [email protected] Subject: Why Import People into ITSM 7 at All? ** All: Inspired by the recent thread concerning the best way to import people into ITSM 7, I wanted to pose the slightly rhetorical question, "Why import people at all?" I'm not certain I agree with the methodology of duplicating data from one existing data source into another. If the Active Directory is an organization's authoritative source of user data, why import it into a separate database? Why not just do a direct pull from the AD on-the-fly? We don't use ITSM here (yet), but we don't import people data-we just pull AD data on-the-fly and it works like a champ. Thoughts? Norm __20060125_______________________This posting was submitted with HTML in it___ __20060125_______________________This posting was submitted with HTML in it___ __20060125_______________________This posting was submitted with HTML in it___ ________________________________________________________________________ ____ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are" -------------------------------------------------------------------- mail2web.com - Enhanced email for the mobile individual based on MicrosoftR Exchange - http://link.mail2web.com/Personal/EnhancedEmail ________________________________________________________________________ ____ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are" ________________________________________________________________________ _______ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are" ____________________________________________________________________________ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are" -------------------------------------------------------------------- mail2web.com – Enhanced email for the mobile individual based on Microsoft® Exchange - http://link.mail2web.com/Personal/EnhancedEmail _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"
