2 of 2 people found this helpful
I'm curious, could you link those articles which suggest building as separate containers? I've never heard of anyone using that approach, and I cant think of a reason why. The only reason I could imagine it done that way is because someone migrated from v11 to v12 using AMIGO, and in v11 they had separate workspaces for each (v11 didn't have the container/item concept).. and this is one of the reasons I always recommend against AMIGO tools here because they don't take advantage of the v12+ architecture.
My general rule of thumb is a separate container for each functional area. So for 'Service Desk' I usually include what you've listed. I might have another container for Change and another for Release, or combine the two into a single one. Depending on the environment.
I'm not sure what most people do, but I can tell you what I recommend and what I've seen. Most of what I've seen, people tend to build from scratch. The provided Business Processes are generally used for training or as reference, rather than actual usage or starting point. The Service Desk container within the ITSM Business Processes isn't half bad, but it's still not ideal. Those Business Process templates were created when v12 first came out, and haven't been updated a whole lot since then.
What I recommend, is look into a pre-built environment like the FootPrints Advanced Starter Template (FAST). It's basically like the ITSM Business Process, except on steroids, and includes far many more processes, better (IMO) and fully designed, and includes all of the things the business processes cant do: consoles, portals, roles, documentation, import packages, etc. You can check out more about FAST here: FootPrints Advanced Starter Template (FAST)
2 of 2 people found this helpful
I am one of the people who DO NOT recommend a separate item for Incidents vs. Requests on most engagements. The taxonomy we use as part of the ticket can drive if it is an incident or request.
The reason why I recommend this is because every item that you set up has its own set of business rules, workflows, fields, etc. and you can only share fields amongst them. So you are doing two sets of templates, two sets of business rules, all for the same FUNCTION, Service Desk support. That's just doubled your administration.
a few other notes: If you ever plan on doing email support, you basically have to have an address for incidents and requests and your customers shouldn't have to figure that part out. Or you wind up with (yet another) item that acts as your dispatch.
Also, in my experience, figuring out permissions becomes more complicated (IMHO) with multiple items per workspace also. You can want some folks to have permissions to the incident record but the problem record and then you have to do another role.
Of course your mileage may vary. hope this helps.
Interesting approach Linda. Does that work well with Service Catalog? Generally my approach - product agnostic - is you have a single point of contact email address and that is use for break/fix issues only (Incidents) and if the end-user wants to request a service, they have to login and use the Service Catalog to fill out the form. Prevents the Service Desk staff from 'wasting time' filling out forms or answering questions on the end-user's behalf.
But that approach doesn't work for everyone, especially those who have very basic processes or have never distinguished Incidents from Service Requests and instead just had 'tickets'. So if I cannot get an organization onboard with the more advanced processes, in those instances I've had to basically just forego using the separate Service Request item and Service Catalog in favour of just using the Incident item and setting the 'Type of Incident' field from 'Break/Fix' to 'Service Request' and rolling that way.
If you do separate the Service Requests and Incidents as Items, what do you do with the "Type of Incident" field? Delete it?
From what I've read, ITIL categorization of incidents goes Type, Category, Subcategory. The out-of-the-box Type field seems to be more for the "single ticket" experience where the item Type is used to define incident vs service request, but if an incident is a separate Item, what is the purpose for Incident Type? It seems redundant. Well, of course, its Type is "Incident" because it is an incident...I am still researching Incident "types".
2 of 2 people found this helpful
I am a very firm proponent of Service Catalog so I think it works great with a single record (or, in ESM implementations, multiple records). Typically we say "Call the service desk if your work is stopped, otherwise use the service catalog/portal". I try to discourage email support wherever possible but its hard to convince customers that it is going the way of the dinosaur (see HDI best practice for supporting documentation), and while it would be great if organizations could continue to offer email support, can they really afford to?
Also, the taxonomy is worthy of discussion - when I first starting delivering Footprints circa 2012, BMC taught the Noun-Noun-Noun taxonomy approach, with a separate stand-alone field called "Action" or "Activity" that was the Verb. The verb designates if it is an Incident or Request (For example, if the action is "troubleshoot" the ticket is an incident if it is 'add' then it is a request). This approach is basically saying "Everything that can be requested can likely break too".
And of course, there is also much discussion to be had about HOW that service catalog should look. Do you put (*for example), do a service for every single application? ITIL says that these are separate service, but then you wind up with a tON of services.
But i digress. In our pro services group, there has been much discussion/contention/fury over the single record vs. multiple record approach and our standard has been to do a single record for incident and request, so my opinion is just one of many. I've done over 500 implementations and have only gone with two items for an incident/request about 5 times and that was for groups that outsourced request management. I also hate the idea of leaving my service desk manager/admin two places to go to make changes (I've been that person before). Typically our customers are smaller companies that are running lean and are too busy to keep up with duplicate changes IMHO.
Hope all of this helps!
Hi Nicolas, I'm new to Footprints but have been a BMC Remedy consultant for many years. I have heard from other trainers and colleagues that it is common to build ITSM functionality from scratch in Footprints, rather than use the out of the box container. I had actually come to the communities to get more information on this when I found your response in this thread, and it sounds as if you share this view.
If it is indeed the case that most clients build their ITSM container(s) from scratch, would I be correct in saying that most Footprints installations are custom configurations, as opposed to BMC Remedy ITSM and other similar tools where it is pretty much a given that the client will at least start with the out of the box ITSM modules, even if they do some degree of customization to them over time? I would imagine many footprints installations are similar by virtue of hopefully being aligned to ITIL and that things like the Service Catalog may be set up similarly, but that the individual workflows, forms, business rules (naming convention, order and composition) would be different in each of these installations if these are all scratch build by different Footprints administrators/developers. IF I'm on the right track here, then it seems like Footprints is more like a "platform" on which to configure applications, rather than an "ITSM Tool" that's ready to be leveraged out of the box....similar to the BMC AR System, on which ITSM (and other) applications can be build from scratch.
Would you mind letting me know if I'm on the right track or if I'm missing something?
Hi Tayler McLean, you are right. Generally I compare FootPrints to Remedy AR, and FootPrints + FAST (FootPrints Advanced Starter Template) to Remedy ITSM. Although there are a few notable differences.
Remedy ITSM is owned and developed by BMC, whereas FAST is owned and developed by RJR Innovations (though Remedy ITSM did start out by a partner as I understand it before BMC acquired it). Remedy ITSM is generally not overly configurable, whereas FAST does not prevent any configuration. And Remedy ITSM is upgrade-able whereas FAST is provided as a 'starter template' and future configuration is done ad-hoc.
In the early days BMC pitched that you could implement FootPrints with very little product training if any, and very little process knowledge. Basically, that anyone in IT could setup and administrate the platform. That message I believe, IMO, was quickly turned around since it's very obvious that your experience with the product depends more on how the product is designed and configured rather than the product itself.