IBM uses this sort of thing for it's mainframe maintenance folks, as well as AIX system support. It nails the low hanging fruit and if all else fails, identifies an area to look at closer. Our product now has an LDAP server for authentication (or Active Directory for those inclined), a Security Service that adds our own distinctiveness to the authentication process, 4 different services to maintain current data, history, watch for events, etc. and both local and web based clients. About 500k lines of code that runs on 14 different platforms. It becomes a real headache when all you get is an error "Unable to log in". I know, the software needs to be a bit more specific, but since a lot of the software is OSS, we don't have much of a choice and we want to minimize the number of changes we make in the OSS software. The support folks need to dig through logs to find what errors were generated where. Thanks everyone, for the suggestions. Josh Welch <josh at joshwelch.com> wrote: Quoting Wayne Johnson : > I know this is a bit off topic... > > Our support organization is trying to create a problem determination > guide for our product. What I mean is a "scripted" flow chart that > they run through to try and isolate (or even fix) a customer's > problem. The biggest issue I see with this is that as a product > changes over it's lifetime, the contents of this guide will change. In > addition, we'll want this to be developed by the support personal as > they gain experience with the product, finding new diagnostic > procedures and tools. > > This is likely something built on a > hierarchical database with a bunch of questions like, does this work? > Does that error occur? Is there this message in a log? > > Anyone seen this? Any suggestions. > Yeah, I've seen this to varying degrees of success. If the product for which you are trying to do this has any degree of complication, then it's damn hard to put together a document of this sort. There are too many ways that a troubleshooting process can fork. I'm assuming the point here is that you're looking to get new people up to speed in a rapid fashion, correct? Your best bet is to identify the low hanging fruit, those simple issues which address a large number of your problems, and tackle those. That should get you part of the way there. Your next bet bet would likely be to break down the product into specific areas of functionality. Perhaps have a top level guide that helps your support staff to determine which area the issue lies in. They then turn to the document for that particular area which drills down more deeply into specifics. It would seem that this format lends itself well to a Wiki, I've never actually gotten to implementing such a thing but it's great in theory. Josh _______________________________________________ TCLUG Mailing List - Minneapolis/St. Paul, Minnesota tclug-list at mn-linux.org http://mailman.mn-linux.org/mailman/listinfo/tclug-list --- Wayne Johnson, | There are two kinds of people: Those 3943 Penn Ave. N. | who say to God, "Thy will be done," Minneapolis, MN 55412-1908 | and those to whom God says, "All right, (612) 522-7003 | then, have it your way." --C.S. Lewis __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.mn-linux.org/pipermail/tclug-list/attachments/20071112/24044fda/attachment-0001.htm