The following web demonstration of Microsoft Sharepoint, Office and Outlook was created by one of ICCM’s key partners in North America; Whitlock IS (www.whitlockis.com)
This short video clip shows how ICCM e-Service Desk is leveraged through Microsoft Sharepoint, as well as the integration available to Microsoft Office through smart-text binding and the MS office ribbon bar capability. Yes, you could completely operate e-Service Desk through Sharepoint, thanks to its use of webparts technology for it’s interface. Other integrations;
- Tasks resulting from process orchestration can be revealed through Microsoft Outlook.
- Planned Service Outage calendars can be shared through Outlook.
- Microsoft Word and Excel documents can be linked to folders within e-Service Desk (folders are Incidents, Changes, Problems, etc).
Microsoft Integration Demonstration
Tags: ITSM, Microsoft, Office, SharePoint
Posted in ITSM | No Comments »
As noted in my blog entry “The Difference between traditional IT Service Management Applications and a BPM Based IT Service Management Solution” there are many benefits that result from a Business Process Management (BPMS) based Service Management solution such as ICCM e-Service Desk. The following demonstrates and highlights an example of how BPM technology is applied to the ITIL Event Management process. Event management existed in the vendor specific reference process models that I used prior to the introduction of ITIL v3. Fortunately, Event Management survived and was included in the final drafts of ITIL v3. Incident Management, when integrated technically, and from a process perspective, is where a good deal of technical integration and automation takes place. Unfortunately, this automation sometimes leads to unintended results and a ton of effort.
Traditionally, when integrating monitoring systems that generate events into a Service Management or Service Desk solution, they most often “dump” alarms directly into the Incident Management process. This integration is often very complex as well. The resulting “process problem” creates the need for “mass deletes” and purges to deal with incidents that aren’t actually incidents. This is an obvious waste of resources, but more importantly, it creates a number of inaccuracies that get recorded and consumes time for agents and/or managers to fix the problem for reporting.
Prior to joining the ranks of ITSM consultant, I used to work in Enterprise Systems and Network Management solutions. It was always best practice, and still is, for correlation, summarization, filtering and suppression to occur as close to the source as possible and within various element managers such as the Network, System, and Application management platform. Normally, only events that are necessary for service reporting, and/or require operational intervention should be recognized. If that is properly configured (which is rare but does occur), then the next step is to manage and control what enters the Service Desk. Event management is about managing and monitoring events, resulting from alerts, as objects with a lifecycle, similar to Incident, Problem, and Change management.
Some terminology first;
- Folders – A folder is the object that progresses through the procedure. Each time a business process (i.e. BPM procedure) is initiated; the system creates a folder containing one or more electronic pages of information. When an end-user opens the folder, these pages of information are displayed on separate tabs. At the bottom of the window, action buttons are displayed. Users can add or edit the information on the folder pages by clicking on actions. A folder can also contain documents. These documents are attached to the folder using a Clip.
- Stages - A stage is where the folder is in the process. Stages can be thought of as the place where the folder stops, awaiting an action like where a paper form stops on a managers desk before they approve or reject it. There are six types of stages in BPM;
- User – where an action is required by a single, specific user, a user stage is specified.
- Group - where an action is required by one (non-specific) member of a group such as a support team or a receptionist pool, a group stage is used.
- System – where no user intervention of any type is required and where system validation/ automation is required, a System stage can be used.
- Sub-procedure – interrelated processes may need to complete in parallel rather than sequentially. Sub-procedure stages are used for this, linking additional maps (called sub maps) back to the main map. Sub-procedure stages can be queued to continue when one or all of its sub maps have finished.
- Common – actions from a common stage can be applied to multiple stages on the same map, eliminating the need for duplicate actions around several different stages.
- Archive – when a folder reaches an archive stage, the process is completed and when the folder is no longer active and cannot be viewed by the Client. This information s still in the underlying database, and can be reported on using reporting tools.
- Actions – Actions represent the activity that happens to a folder as it progresses through a procedure. Actions can loop back to the same stage or can link stages which would cause the folder to move from the originating stage to the recipient stage. There are five types of actions in BPM;
- User – Actions performed by a user, such as entry of data and making decisions via buttons associated with a form. These actions automatically appear as buttons at the bottom of a form in the Client.
- Timed – Actions that are triggered by a date-time condition. Timed actions are triggered after a set time period before or after a specific event.
- Conditional – The Process Engine can test a condition and performs actions based on the result. Conditional actions are executed when their only start action if property is met.
- Rendezvous – Once a sub-procedure has been completed any folder waiting at a sub-procedure stage can be moved on using a rendezvous action. This action can be set to be dependent upon any or all of the sub-procedures being completed. This action can only be drawn from a sub-procedure stage.
- Flagged – Flagged actions are used to link maps and external applications with a BPM procedure. A procedure may contain more than one map, allowing actions in one folders life cycle to influence actions performed upon another. Flagged actions are triggered by flags, which can be raised to declare that an event has occurred and to pass data between maps.
- To Do List – Each users “To Do” list contains folders on which the user is required to perform an action. The BPM Engine automatically updates this list whenever a folder reaches a stage for which the user is defined on the To Do List.
- Watch List – The Watch List is similar to the To Do List. However, users do not normally have to perform an action on folders on their Watch List the folders are just displayed there so that the user can monitor the status of the folder as it progresses through the procedure. Just like the To Do List, the BPM Engine automatically updates the Watch List whenever a folder reaches a stage for which the user is defined on the Watch List.
The following diagram is the event management process within ICCM e-Service Desk. This is a “Map” which essentially shows the stages and actions in a given process. The important thing to note is that this diagram isn’t just a picture. It is the model that is used to drive the application.
ICCM e-Service Desk Event Management Process Map
As you can see, the process is defined from start to finish and is not embedded into an event management application. If you wish to change any flow, integration or activity, it is done to this map. Forms are also associated to each of the stages and actions.
You will notice the flagged action (green flag) which would be the flag raised by monitoring systems to generate an event. As indicated before, flagged actions are how external systems, such as monitoring systems, as well as processes within the system, integrate with one another. This is done via web service, API, database or any number of other triggering mechanisms. Subsequent to these, you can see the manual actions (a hand), timed actions (a clock) and conditional actions (a question mark) that identify filtering and suppression that takes place. As long as the monitoring system could raise this flag and pass data, it could easily be integrated to e-Service Desk.
The Event Manager would actually use a role based “Rules configuration” form such as the following. Administrative forms allow for the modification of non-folder data, such as administrative data;
ICCM e-Service Desk Event Management administration form.
From this, you can see the Event manager (the person) has the ability to identify events that should be suppressed, filtered, closed, turned into an Incident, Change or Problem, etc. It’s very easy and you have the ability to quickly modify the rules that the process executes against. With the Enterprise nature of BPM, handling 40,000 new folders a day is easily handled with two process engines and more could easily be teamed if needed should that volume grow.
Hopefully this blog entry has provided you with an idea of how easily and quickly e-Service Desk is leveraged for Event Management. The same holds true for any of ITIL v3 modeled processes within ICCM e-Service Desk. This is also how new processes are designed, rendered, orchestrated and integrated as well.
If you have any questions or would like to see Event Management and/or any of the other processes, please send an email to jclark@iccmco.com to setup a web demonstration.
Have a great day!
Tags: ITSM ITIL BPM Event
Posted in BPM, BPM, Event Management, ITIL, ITSM | 2 Comments »