Hey all, honestly i do not see the point in pumping up OTRS with an asset management plugin as this topic is quite complex. If you take a look at a global market for ticket and asset tools, you will realize that if a tool combines both features it is either: - lacking basic functions of either AM or IM - to pumped up where nobody needs those features
Personally I am only aware of one German and one American tool that combines both and I am neither totally satisfied with one nor the other. Sure ... would be quite handy for agents to directly check customers configuration while creating a ticket and such but where would you stop with AM functionality? Just basic hardware discovery? Additional OS, Software etc? Licensing? The scope of IM and AM is, imho, ways to huge for one tool to fully cover. Just my 2 cents. With kind regards, Studienkreis GmbH Mark Grzella Junior IT-Projektleiter Universitätsstraße 104, 44799 Bochum Tel.: 02 34/97 60 - 404 mgrze...@studienkreis.de www.studienkreis.de AG Bochum HRB 4581 Geschäftsführer: Franz Dahlmanns Bernd Kreissig (Sprecher) Bastian Schmidt-Faber -----Ursprüngliche Nachricht----- Von: otrs-boun...@otrs.org [mailto:otrs-boun...@otrs.org] Im Auftrag von Michiel Beijen Gesendet: Donnerstag, 28. April 2011 01:59 An: User questions and discussions about OTRS. Betreff: Re: [otrs] OTRS ITSM : computers discovery Yeah; this is a valid point: you really should control the changes done to your CMDB. That said, auto-populating and/or updating the CMDB with a discovery tool should not lead to an out-of-control configuration management process per se. The problem is that you would NOT want to populate and/or maintain your CMDB manually once you have a significant amount of CI's. (Did you ever deploy 50+ new servers and manually enter the data in the CMDB? That is *not* a good Config Management practice, that's asking for input errors!) Also, please bear in mind that it's great if you have a manually maintained CMDB but it's CRUCIAL to verify this against the actual truth so you can check if you're still in sync. Of course discovery tooling can only supply a *part* of this truth, using discovery data you usually can not tell: * whether or not a machine has a support contract * the purchase date, PO number, vendor information, cost center * the physical location (room x, rack y) * the kind of service it's running, and if it's a test or production environment etc; this data needs to be manually added to the CMDB. One great option would be if you would get 'diffs' of your CMDB using discovery tooling or such and having the ability to link this to changes; for instance, if a server suddenly reports a different IP address, or if your discovery tool finds a new router on the network, you should be able to get a 'diff report' for this and link it to the change request that made this happen. In my opinion the process of updating a selected amount of fields from discovery tooling is completely valid and good practice, as long as you have and monitor these 'diff reports' and make sure you link these to the change requests or other sources that made it happen; this is also a very nice way to make sure no unauthorized changes are performed. @Nils: what do you think? -- Mike On Wed, Apr 27, 2011 at 10:38 PM, Nils Leideck <nils.leid...@leidex.net> wrote: > Dear all, > On 27.04.2011, at 21:50, Leonardo Certuche wrote: > > Please keep in mind that auto-populating your CMDB using a discovery tool > will lead to an out of control configuration management process. > > What we do is the following: we get the inventory from OCS, export it to > CSV, and then import it to OTRS using the ImportExport feature. That way > you'll have an starting point for your CMDB and any change you perform after > that should be done by hand either through the change process or the > configuration process. I know it sounds too manual but that way you'll keep > control on the changes performed to your configuration items. > > I can’t give enough acknowledges to what Leonardo said !!! > Configuration Management and Inventory is a different and should stay a > different !!! > Cheers, Nils > -- > Nils Leideck > http://webint.cryptonode.de / a Fractal project > > --------------------------------------------------------------------- > OTRS mailing list: otrs - Webpage: http://otrs.org/ > Archive: http://lists.otrs.org/pipermail/otrs > To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs > --------------------------------------------------------------------- OTRS mailing list: otrs - Webpage: http://otrs.org/ Archive: http://lists.otrs.org/pipermail/otrs To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs --------------------------------------------------------------------- OTRS mailing list: otrs - Webpage: http://otrs.org/ Archive: http://lists.otrs.org/pipermail/otrs To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs
