The following points are telltale signs that your ITAM processes need an overhaul:
Pointers to watch out for when assessing “what good looks like” in respect of ITAM process engineering:
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:
The link between ITAM operations and 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).
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