It was an awesome day today. To follow up on my previous post about our participation at the annual itSMF Arizona Local Interest Group summit, this was indeed the day for sharing best practices - a packed, day-long event filled with industry veterans and luminaries.
Continue reading "Infosys' day out at the annual itSMF AZ LIG summit" »
Every now and then, one comes across the term 'Best Practices' especially within the IT Services industry.
This term is used far and wide by teams within the enterprise, IT leaders and service providers. Ever wonder what this truly means? Or to put it in a more structural context--
· What is the meaning of 'Best'- i.e. 'Best' as compared to what?
· What is 'Good' and is 'Excellent' better than best?
· Does 'Best' result in value for the business always or only sometimes?
· What is it's shelf life? When does 'Best' become obsolete?
· How many people does it take to recognize a 'best practice' and do they need to be in particular roles?
Continue reading "The truth about Best Practices and everything in between" »
In my last blog I mentioned about the importance of Data Governance and its evolution. I also tried to focus on the reasons behind the need and the opportunities that lie ahead. In this blog I would like to elaborate further on the challenges/needs mentioned and also try to outline ways to prevent/resolve them. I will focus on some seemingly obvious but mostly ignored concepts. Link to my previous blog Data Governance for SaaS (Part 1 of 2)
1. Firstly, the most obvious one... Involve all stakeholders and have expectations and solutions balanced and agreed upon at all times.
In IT Asset Management certain asset types carry confidential information (mobile sim PIN, User password, delegation rights control etc.). Managing security breach due to access of vital data via different screens or unforeseen entry points (i.e. via the reporting module or direct target url entry) is always a challenge.
To avoid this there can be data exchange agreements between the data provider and consumption teams. So by virtue of such agreements across the enterprise there can be a defined understanding for handling critical information across the various system records, archives etc. As the impact of these are fairly systemic its build should include expert advice & consent from Enterprise Architects, Information Security, Access & Risk Managers.
2. Follow the middle path... One should not relying on technology or tool alone to solve all their data problems.
Managing sensitive data (i.e. financial, health, legal data) in Incident, Problem, Change, Release, Service Catalog Management etc. often defy security rules. There are times when the business may need urgent solutions and ignorantly attach/share restricted information. This is unavoidable but nevertheless it is possible to have alerts based on the nature of the data that is being shared (A form of context driven help and support).
Sometimes, simple features and a little more thought goes a long way towards preventing inappropriate data sharing and mishandling. Process design, usability and training along with technology should be managed as a single piece to help achieve effective outcomes during implementation. Don't just focus on one aspect too much but rather focus on the whole (Ashwani's blog has some well compiled best practices around this).
3. Innovate... Have an integration framework in place and continuously weigh out options, consolidate and evolve.
Building interfaces, channeling data/triggers for Deployment provisioning, Product Catalog etc. and compliance could be the biggest security juggernaut. Having reliable interfaces to data sources and to be able to equally disperse information is priority for SaaS systems.
In one of our implementations we managed this via 'web services' as it was a strong capability of the platform we chose (Please refer to my earlier blog 'ITSM - Choice Matters'). With the right data structure we were able to have it exchange real-time updates across different tools (i.e. Scheduled jobs via inbound email rules is also effective but not preferred in all cases). The needs can be different but having a consolidate way of managing this maintains predictability and is more reliable & scalable option.
4. Think!... Getting a little more out of the tool by means of customization is tempting but it is important to first challenge the need and thoroughly evaluate the solution.
There will always be a need for new processes and modules (i.e. items which do not form a standard module in some tools). Most SaaS tools generally come with powerful admin configuration features. These are sometimes extendable to create one's own modules which can be integrated to leverage the combined benefits with existing modules (i.e. To avoid email overload to end users the need to build a subscription based project/release communication management module).
It's important to map and keep an alignment on the requirements, processes workflows and overall data architecture of the tool. Of course there is always a fine line between plain configuration and the need to customize (Please refer to Satsang's brilliant blog where he weighs out the options). Customizations are usually an overhead and this should be seriously weighed against priority and needs with the feedback from technical architecture and the vendor.
5. Celebrate... Dashboards are infact the most alive part of the system where the benefits of Data Governance become apparent. Groom and cherish it!
Graphical plans and charts (for incident, problem change reports, rollout plans, conflict detection, release schedules etc.) are no more nice-to-have's but rather a must. Data governance is not just about data security but also about combining data to create meaningful information for tracking, reporting, continuous improvement & business value. Reports were usually assumed to be basic and at best just data dumping capabilities.
Powerful visualization and report generation features are a valuable assets of SaaS tools today and some have taken a leap in redefining this. The concept of dashboards is a powerful one and this should be factored in early during requirements so that data structures can be defined with useful outcomes in mind.
Just to summarize... its common that project teams tend to ignore the most obvious. They sometimes push too hard in one direction and tend to deprioritize other important aspects. It's often a shame that innovation and brain power (or even gut feel and experience) has to give way to bureaucracy and heavy processes. The solutions are there and we obviously know them. It just takes a little more from all to appreciate and manage it instead of letting things go out of control...
It's critical that IT Departments are abreast with not only the current but also future needs of their business. This is easier said than done... but with SaaS in the picture, software development and deployment is not the same anymore. The ease of evaluation and adoption is quick and hence it's important for IT leaders to be ahead of the curve in knowing what's around and introducing these within the organization where they see fit. This should be done before the businesses start taking independent decisions without IT in the picture.It is important to understand and realize that rapid prototyping possibilities of SaaS does not necessarily reduce the expected time for analysis and testing. These are still critical and required. Cloud adoption is quick but this should not make it vulnerable to business pressure and prone to hasty signoffs or decisions. SaaS does not make Data Governance easier nor does it make it riskier. The paradigms are shifting, the possibilities are surely greater but dealing with it will require more focus on vision, innovation, creativity and most importantly leadership.
Share your thoughts!
- Posted by Ravindran A Varier
Albert Einstein had said that if the future generation does not find any faults in his theories, then there has been some major mistake somewhere, or something like that! That was the conviction that he had that the future will question the theories of the past.
I draw inspiration from this statement from the great man. We all would have been told in our school days that we should not copy from our neighbor. But I draw inspiration from Albert Einstein and hence question this theory! This reasoning and the resulting thought process led me into the present day corporate best practice of Reuse! (I know you are surprised by the connection. In fact, Einstein would have stayed clear of his statement if only he knew it could be comprehended in this way too! 
- Anurag Bahal, Senior Consultant, Infosys
How do we create a common language of Communication and create Team Synergy using metrics?
America’s first billionaire J. Paul Getty said it “I would rather have one percent of efforts of a hundred people than a hundred percent of my own efforts”
In my earlier blog on Change Management metrics, I wrote about how several organizations use total number of Changes as a measure of the success of their Change Management process. Here, I would like to share with you some practices I have found useful in deciding what type of metrics to measure.
Continue reading "Musings on Change Management Metrics - Part 2" »
The total number of changes has gone down - our Change Management process is a success ... Is it?
A while back, I was assisting an organization to implement ITIL based Change Management process. Apart from (the usual?) complexities of implementation, something that struck me was the trigger for this implementation. "There are far too many changes within our organization - we need to reduce the total number of changes".
So, why am I writing about this? Well, for one, I am still quite amazed by the number of organizations that use total number of Changes as a primary measure of how successful their Change Management program is.
Does it make sense? No? So, is "total number of changes" a wasted metric? Not really. Arguably, it is a relatively easy and very visible metric to measure. But is it sufficient? Does it give a sense of what impact these changes have had on services? Does it indicate whether testing happened rigorously? Or, for that matter, does it even indicate whether basic adherence to process happened or not - such as having a back-out plan, impact analysis carried out, etc. Obviously it's not a stand-alone metric.
So then, what's a better measure? Hmm ... we'll get to that in a bit.
Continue reading "Musings on Change Management Metrics - Part 1" »
