Telltale Signs of Poor ITAM Process
The following points are telltale signs that your ITAM processes need an overhaul:
- They don’t have a discernible outcome or purpose
- They cannot demonstrate links to ITAM/IT and/or Business strategy
- They have no associated KPIs
- They are too big – therefore unwieldy and not engaged with
- They are too small – and therefore ignored and not engaged with
- Function steps refer to departments, but no one in that department has taken ownership of who is completing that task
- The processes have never been reviewed
- The documentation supporting the processes has no date/version control
- The processes don’t have an owner
- The processes don’t have senior management backing
- The processes don’t demonstrate how they link with other processes
- The processes don’t model the real world – i.e. what happens in the event of a rejection of data or a decision?
- You do not have a plan to assess process performance (a process within itself)
- You do not have a plan to assess the relevance of the ITAM processes to your ITAM/IT/Business strategy (typically a Governance process)
- Your processes exist exclusively for the benefit of ITAM – other IT disciplines could greatly benefit from some of the reports ITAM is capable of
- Your process documentation fails to get the relevant message across
Pointers to watch out for when assessing “what good looks like” in respect of ITAM process engineering:
Modelling the process itself:
Goal setting: Make sure the goals and ambitions of the process are clearly defined BEFORE starting to design the process – this prevents “good ideas” creeping into the design, and overloading the process with extraneous activities.
Makes sure your Primary and Secondary Objectives are:
The following entities should be included in a process map:
- Event/Trigger: This is a circumstance or activity that arises that drives a resultant action (function step) to occur.
- Function Step: The intended activity required of a system/person or department in response to an Event/Trigger
- System: The system/software required to complete a function step
- Job Title: The person/department required to execute and/or interact with a function step NB: If you nominate a department to undertake this activity, ensure ALL of the department can successfully complete this task
- Data: The import and export of data required to complete a function step, and any resultant data that the function step exports
- Adjacent processes: SAM Processes do not exist in isolation, so model the connection between processes to demonstrate a wider workflow perspective.
- Supporting Documentation: If reference material is required to be read to understand how to complete a function step, then this too should be referred to in the process map
- Quality Assurance: Identify your Key Performance Indicators (KPIs) to enable the measurement of how well/badly a process is running – that way, if a process is not performing well enough, you have the statistical data in place to understand (or at least investigate) why, which then supports process re-engineering.
- Risk: If your process is susceptible to a particular risk which could prevent successful completion, then model that risk in your process map.
The link between ITAM operations and Business Strategy:
- ITAM Operations supports ITAM Strategy =>
- ITAM Strategy supports IT Operations & Strategy =>
- IT Strategy supports Business Strategy
Good governance should ensure that a periodic re-visit of the direction the company is taking, feeds IT requirements back to the IT department, and in turn those IT requirements (where appropriate) place demands on the ITAM function. If ITAM processes do not support either IT or business goals (directly, or indirectly) then they should be re-engineered. As well as being proactive in aligning IT and ITAM to the direction the business wishes to head, Business Strategy should also be under-pinned by formal Risk Analysis. A business risk register should look to capture IT risk as well, and so look to remediate risks with the resources at its disposal (including ITAM).
Other points to consider:
Size of Process: The size of your process should be dictated by the steps required to successfully complete the primary and secondary objectives of each process. It’s really a judgement call as to how big too big is, but generally speaking if a process has more than fifteen steps, then start considering whether you are modelling two or more process in one go.
Scope/Reach of Process: Your process should consider its effective reach and the impact technology and personnel have on that reach for a process. E.g. a Software Change Management process utilising System Center Configuration Manager, is not going to be of much use when software needs to be deployed to your IBM i-series estate.
Exception Loops/Modelling in the real world: Try to foresee the unforeseen – life sometimes doesn’t smoothly, but if you are in a position to model those moments when technology might under-perform, or even when personnel have an off-day, then minor errors can be mitigated and prevented from becoming larger errors further downstream.
Continuous Improvement: Take your processes, and understand what it is they have to do in order to drive SAM Maturity in your organisation – e.g. if you wish to drive down the amount of shadow IT in your organisation, then look to start with including 90% of your device count within your ITAM scope and over time work towards achieving 100% (or as close to 100% as you can reasonably achieve)
Process Maps: These should offer a “30,000ft” view of what takes place, including all of the information covered in the bullet pointed list on the previous page
Process Definition Document (PDD): Imagine if a Line Manager or Head of Department wished to understand the “why” behind the “what” of a process, then a PDD should capture such information as Primary and Secondary objectives, Business Requirements, IT Requirements, Best Practice & Regulatory Requirements and relevant KPIs used in measuring the process. If processes are time-sensitive, then such information should also be contained in this document
Standard Operating Procedures: Imagine someone within a SAM Team (or even a stakeholder in a different department) starts a new job with your company and they have no idea what it is they are expected to do – then a Standard Operating Procedure should offer them a keystroke-by-keystroke run-through of how to complete a function step they are expected to complete.
The diagram below offers a relationship map of how the documents above inter-relate with other project/BAU (Business As Usual) documentation:
Rory has published a process kit which contains 22 ITAM process maps and walkthroughs. ITAM Review readers can claim a $50 discount by quoting code ITSMREVIEW50 using this link: Process Kit
About Rory Canavan
With a technical background in business and systems analysis, Rory has a wide range of first-hand experience advising numerous companies and organisations on the best practices and principles pertaining to software asset management.
This experience has been gained in both military and civil organisations, including the Royal Navy, Compaq, HP, the Federation Against Software Theft (FAST) and several software vendors