This week, our team was in Louisville, Kentucky for the ITSM Fusion Expo. We provided custom demonstrations of IssueNet and ScreenConnect for all who stopped by. 

Our next show is the HDI Service Management Conference & Expo in Miami, Florida, coming up on October 6th. We hope to see you there! 

Elsinore Technologies announced July 21, 2010 that it will be exhibiting at the 2010 HDI Service Desk Expo in Miami Florida. The event scheduled for October 6-8^th at the InterContinental Miami is an annual conference that brings together members of HDI community to discuss industry related topics such as Service Management, Governance, Service Quality, and much more.

This show appealed to us for a variety of reasons, but we ultimately made the decision because of the HDI community itself. Their focus on quality, knowledge sharing, and innovation mirrored what we as a small software company are trying to achieve every day. As we worked with the Expo team for several months learning, reading, and asking questions it was clear that HDI had a well thought out and focused event which we wanted to be involved with going forward.

The entire team here is excited about our first HDI Expo and no it’s not just because it’s in Miami! So if you are in Miami October 6-8^th and you want to talk about ITSM, Issue Tracking, or Remote Support stop by booth 3 and say hello to Jeff, Jake, or Morgan.

Elsinore Press Release

HDI Service Desk Exp 2010 

Has your team ever complained about the confusing issue submission form?

Have you had to alter how you’d like to handle certain issues due to the constraints of your software?

Do you have an issue tracking solution for facilities, software development, IT, HR, product management, and your help desks?

There are many issue tracking solutions available, but most are designed specifically to work within a certain department or group. For example, software development has a host of industry-specific solutions. These solutions can be tweaked or modified to marginally work for other teams, but inherent limitations persist due to the software’s designs.

IssueNet was developed with an object-oriented architecture that allows teams to completely customize all facets of the software to meet their specific needs. The options are endless and quite exciting when you consider the opportunities. For example, each issue type can have its own form, workflow, users, and notifications. Additionally, a single database can be used between all the solutions to allow better communication between teams, making implementation quicker and easier. Take a look at what an object oriented issue tracking can do for you! http://www.elsitech.com

Many global organizations are working on standardizing the best practices for workflows. One of the most notable practices is the business process modeling notation (BPMN). The BPMN provides a set of symbols and guidelines for charting the flow of a business process. In this second installment of our workflow discussion, we’ll talk about the different elements that comprise a BPMN compliant workflow.

 

Annotations – These are small text paragraphs that are often added by the workflow designer to explain what is being done at that stage of the workflow. Annotations can provide additional information, but they can also take up a lot of additional room on the canvas. Because annotations are not necessarily required in a workflow, there are a few modes of use:  always visible, visible if the mouse is over a particular element or icon (also known as “tool tips”), or toggled on and off as the user requires through a button or similar mode of use.

Events –Events, denoted by circles, signal “something happening,” such as an email notification, a scheduled meeting, or the end of a particular process. Icons may be present inside the circle, such as an email icon or a clock picture. Though a user will immediately know the type of an event by the icon or color of the circle, the user will not know exactly what transpired during that event. Annotations may be added for clarity, which will result in a workflow with more elements.

Activities –Activities, such as meeting requests and task assignments, are sometimes represented as rounded rectangles with small icons. However, these icons only tell the user that “something” is happening at that point; the user will not necessarily know exactly what happened at a meeting, who is involved, what was said in an email, etc. Having more information about the activities can be useful, but it creates additional design elements in the workflow.

Question:  If you are assigning the same task to multiple individuals, should workflow designers use one task element to represent this activity? Or should the designers use multiple elements?

Gateways – These are elements that take transitions from the output(s) of elements and then transition them to the input(s) of others. There are two main types of gateways: combiners (fork/join) and multipliers (inclusive decision/merge). A combiner takes multiple inputs and creates a single output, while a multiplier takes a single input and creates multiple output transitions. These elements are not required in a process. However if the goal is to show as much detail as possible about the events of a workflow, they can be very useful.

Question:  Should a gateway that has internal logic denote that to the observers of the workflow?

Swimlanes – Represented as horizontal or vertical lanes (often different colors), swimlanes help teams and designers to keep track of what work is done by which department or what category the work falls under. These can add complexity to the layout and design of the workflow.  

There are many more elements within the BPMN standard that can be added to a workflow. Again, however, we must ask the question: which elements are the most important? By utilizing a large variety of geometrical icons, will the workflow become too cluttered, hindering the understanding of the user?

The team here at Elsinore has spent quite a bit of time this past week reviewing how workflows should look and feel to users.  We thought it would be great to hear our customers’ and visitors’ opinions on workflow design usages.

For the purpose of this blog we will focus specifically on business processes, though the principles could apply to any type of organization. A typical workflow diagram will have geometrical elements (such as rectangles, diamonds, and triangles), each representing or describing some action, activity, or decision that has to be made during the process. Most of these elements will typically have a one or two word label to help observers keep track of the flow. These elements are however only a few of the possible graphical and text representations available.

The amount of detail provided by a workflow diagram is determined by the workflow designer. Workflows can be designed at a high level, only outlining the general scope of the process and keeping the layout simple. On the other hand, workflows can be very detailed, showing exactly what activities are being performed, to whom the emails are sent, what divisions are doing the work, who is responsible for scheduling a meeting, etc. The information is all available but the key is balance. When we consider these and other elements that could be represented, are they useful or do they add clutter to the workflow canvas? What elements do you think are important?  And should workflow designers err on the side of simplicity, or should they strive to display as much information as possible?

It’s a difficult philosophy to capture in a single blog, so in the next installment we’ll capture a few of the most common design elements of a workflow and discuss some of their pros and cons as graphical representations on a workflow.

With the transition from ITIL Version 2.0 to 3.0 and the increasing exposure of Microsoft Operations Framework (MOF) the terminology and organization of the terminology used in the industry is changing and evolving.  But am I confusing my customers when I use the old ITIL terms or am I confusing them worse using the new terms they have less experience with? I need a way to figure out what is still the same and what is different in ITIL version 2 and version 3.

So I looked out to the web to see if anyone had done a direct comparison of the terms and books of ITIL v2 and v3.  I found where someone had done a pretty nice write up and several other sources plagiarized the work; but, it was still all written comparisons and I wanted more of a diagram, a drawing, something with arrows!  I never found what I was looking for so between episodes of NCIS last night I resolved my problem.

So without delay here is the Elsinore Technologies ITIL v2 vs. v3 comparison diagram.  If you note any mistakes on my part please let me know and I will correct my oversight immediately.  Regarding the diagram ITIL v2 books are broken out on the left and v3 on the right, the type of arrow doesn’t matter I used a few different styles for aesthetics only, also I added the service desk and variations thereof to the Service Operations book of ITIL v3.

A higher resolution version can be downloaded from our Oversight website at:

ITILv2-vs-v3-Diagram

It doesn’t take but a few hours of searching the web to find that there are quite a few players in the world of certification and IT Operations Frameworks.  The Information Technology Infrastructure Library (ITIL) developed in the UK in 1989 by CCTA which now resides under the ownership of the UK Office of Government Commerce (OGC) was one of the first attempts at documenting the concepts, policies, and best practices for managing information technology (IT) infrastructure.  Over the past few decades IT departments have seen the development of websites, blogs, certification processes, revision changes of ITIL strategies, and teams of consultants grow at staggering rates.  A lot of this could be contributed to many economic factors but I believe the biggest changes are contributed to IT alignment with business units.  As IT services becomes more measurable in conjunction with business unit profitability, company executives can better see the bottom line revenue potential of investing in their IT department processes, training, and service management; not just the hardware and software assets.  With this shift in visibility IT departments go from black boxes which few executives understood to glass boxes that play an immediate role in productivity, revenue generation, and customer satisfaction visible to everyone.  And with this visibility comes money and as companies start spending more of it the private sector reacts providing an increasing number of services and solutions to help fill the needs.

Since its inception both formally and informally the playing field has changed and grown springing up new players such as ITSMF International, ITSMPA.org, ISACA, COBIT, ISO 20000, and Microsoft Operations Framework just to name a few.  These companies coupled with mandated compliances such as Sarbanes-Oxley, HIPPA, and SOX have made IT operations a huge growth area for companies of all types who want to provide their touch, insight, and experience to this unquestionably fast moving and high growth business segment.

But with all of these new players and the push by companies like Microsoft into the market defining new terms and best practices which organizations and sectors of this model will be the industry leaders moving forward.  The direction of operations is changing, in the past few years we have seen the process driven ITIL version 2.0 replaced with a business aligned version 3.0.  And now Microsoft is providing their version of operations framework which is similar to ITIL but has its own unique twists.  So who is going to jump into the mix next?  One thing is for sure competition sparks productivity, new ideas, and new ways of approaching problems.  All though I would like to see continued alignment in terminology I like the idea of new companies pushing the incumbents, if nothing else it gives me something to blog about!

So you need to develop a workflow to resolve an issue but you are not sure where to start?  The following is an 8 step strategy for defining how to resolve an issue.  As long as your workflow encompasses these stages you are probably good to go.  There are always exceptions but these guidelines are a good starting point.

Identify the issue – You need some process or tool that provides the capability to identify what issue you are trying to resolve.  This could be customer focusing but don’t forget about your own employees.

Classify the issue – Ok so what sort of problem are we dealing with?  Is it a software bug, an enhancement request, a customer question, or a flat tire on a school bus?  Classification allows you to determine which workflow should be assigned and directs the issue to the appropriate group or process.

Rank the issue – All issues are not created equal. Say it with me, “All issues are not created equal!” Now that does not mean that any of them should be ignored but it does mean that a problem that has caused your sales to plummet 80% should have more weight than a problem regarding the soda machine in the cafeteria.  Develop a simple but yet flexible weighting scheme a lot of software companies will use a critical, high, medium, low scale while a lot of retail organizations may choose a numerical scale such as 1-10.

Assign roles and responsibilities – This is an important step that’s often overlooked, a good example is when you send an email asking a question and you put ten people in the To: list of the email and label the subject “can you please do this.” Don’t know about you but this doesn’t usually yield a lot of productivity for me, typically I get no responses.  You have to develop a process of accountability with each workflow, make sure each person associated knows what he/she is required to do as part of the process.

*Note – Talk to the team members they know their jobs and where they can best help, maybe you can streamline the number of people required.

Assessment – The team on the other end needs to know what to do with the issue, are they supposed to have a meeting to discuss the best course of action or simply pray to the senior management and await a sign from above.  I have seen both methods work but I typically recommend the more structured path to start.

Recommendations – The team should be instructed to provide a resolution or several possible resolutions to the problem with some pros/cons of each.  From those recommendations a business decision would be made of the best path. 

*Note – The assessment and recommendations stage can sometimes happen at the same time assuming that a representative from all responsible teams is present.  For software developers that might be development, marketing, and sales.  For a municipality that might be someone from city planning, finance, and other relative departments.

Call to action – Once the decision has been made there has to be a way to kick off the work.  This is usually a transition from one stage of the workflow to the next or in technical jargon a workflow state change.  This could be a simple email or as elaborate as your process requires but the point is to make sure all the relevant data and expectations are communicated clearly.

Closure and communication – Alright were done, so what now?  We need some step here to notify the relevant stakeholders of the completion.  In a lot of cases this would just be an email but in others it will be the starting point of your next workflow.  For example the issue might have been a problem with our product documentation so we have fixed the problem but who is responsible for posting the document to the web or reworking the product CD image so that the proper revision is available.  For some organizations this is someone’s job and a workflow is not required but for some larger companies this is another process altogether.

Yesterday I was talking with a friend who asked me what it is I do at Elsinore.  I explained we are an issue management company and the minute the words came out of my mouth I realized the vagueness of the statement.  If I wasn’t already sure, the confused and pondering look on his face confirmed my suspicions.  So like most people I dug into examples, explaining how customers use our software for help desks, call centers, software bug & defect tracking, and a few other examples.  The entire process took me about 5 minutes and if it had been giving an elevator pitch I would have failed miserably.  I needed to be able to explain what issue management is without giving a 10 minute dissertation on the subject. I still need to be able to explain how our products relate to issue management but explaining the term issue management correctly was my first hurdle.

So like most people today I went directly to the almighty source of wisdom, Wikipedia.  There I found a pretty good definition of the term; Issue management is the discipline and process of managing business issues and usually implies using technology to electronically automate the process.   I say pretty good because I am not convinced that if I share this with my friend he will not still have a similar look of confusion but it’s a starting point.

My next step was to interview about a dozen colleagues and friends to get their response to what issue management meant to them.  I did my best to find a random sampling of different backgrounds and experiences.  I contacted people in staffing, construction, software development, stay at home parents, teachers, and engineers.  The responses I got were varied but not surprising, every person I talked with related issue management to their own day to day life and industry.  Staffing people described services to manage labor cost and customer issues, construction managers related the term to managing and coordinating the problems with each build, developers talked about tracking software bugs, and stay at home parents gave examples of scheduling conflicts and work that needed to be completed at home. 

It was becoming apparent that issue management was a marketing buzz word that meant different things to different people, maybe not as vague as terms like “business intelligence” and “B2B” or as over used as “out of the box” or “best in class” but still difficult to quickly explain.  But there was something about this term that resonated with everyone I spoke with today.  They were all able to relate the term issue management to a problem they were having and needed a way to resolve.  I read through everyone’s responses again and it started to mesh, stilling a bit from different passages I have a working definition that I am pretty happy with going forward.  It may still raise a few questions from time to time but overall I think it works. Issue management is a methodology by which problems, events, and other issues are identified, tracked, and ultimately resolved.