Skip to main content

The Consumerization of IT

How many of our colleagues use their own personal devices for business purposes? Now, here’s the burning question. How many employers are aware that they are using those devices? Employees using personal devices at work are part of a growing revolution known as the consumerization of IT, or bring your own technology (BYOT). According to a recent Unisys-IDC study, workers reported that they are using smart phones, laptops and mobile phones in the workplace at nearly twice the rate reported by employers. This disconnect between what workers are doing and what IT leaders believe is happening is echoed in a recent survey of IT security professionals which highlighted the security and management threats posed by the growing use of personal devices like smart phones on corporate networks. About 40 percent of IT security decision makers in the Cisco-sponsored survey said they had experienced a breach or loss of information due to an unsupported network device.

So what’s an IT organization to do? According to IDC, the number of workers using personal smart phones for work is expected to nearly double from 2009 to 2014, and so simply restricting access, failing to measure such practices and failing to provide support isn’t going to work.

According to the Unisys-IDC study: “By modernizing their policies, procedures, and IT systems to harness this trend, organizations have a rare chance over the next 3 to 5 years to leapfrog competitors and over turn existing business models--much as Apple and Google did with their own consumer-led IT business revolutions. Conversely, organizations that fail to prepare for and adapt to this consumer-driven movement will find themselves at a competitive disadvantage and will miss out on rare opportunities to avoid costs, increase their organizational productivity and flexibility, and appeal to a new generation of consumers and employees.” Some thought provoking trends for all of us out there managing services.

So how does an IT department prepare for this or deal with this situation if it already exists? Here are some recommended steps:
  • Do an inventory or baseline of all configuration items as well poll employees about what devices they have and are using both at work and personally. Do this in a way that it does not imply potential punishment, rather for better Knowledge Management of devices. 
  • Compare your inventory or baseline against your service catalog (both from the business aspect and technical services aspect). A widespread use of smartphones may indicate the need for such a means of enabling services. This will allow you to align technologies to the needs of the business and end-user customers.
  • Establish initiatives to identify and implement which of these devices you will move forward with as viable and acceptable means of using for the delivery of services.

 Be proactive in your efforts when it comes to understanding and using technology to enable and support the delivery of value to your customers. It will serve them and you now and into the future.

Comments

Popular posts from this blog

What is the difference between Process Owner, Process Manager and Process Practitioner?

I was recently asked to clarify the roles of the Process Owner, Process Manager and Process Practitioner and wanted to share this with you.

Roles and Responsibilities:
Process Owner – this individual is “Accountable” for the process. They are the goto person and represent this process across the entire organization. They will ensure that the process is clearly defined, designed and documented. They will ensure that the process has a set of Policies for governance.Example: The process owner for Incident management will ensure that all of the activities to Identify, Record, Categorize, Investigate, … all the way to closing the incident are defined and documented with clearly defined roles, responsibilities, handoffs, and deliverables. An example of a policy in could be… “All Incidents must be logged”. Policies are rules that govern the process. Process Owner ensures that all Process activities, (what to do), Procedures (details on how to perform the activity) and the policies (r…

How Does ITIL Help in the Management of the SDLC?

I was recently asked how ITIL helps in the management of the SDLC (Software Development Lifecycle).  Simply put... SDLC is a Lifecycle approach to produce the software or the "product".  ITIL is a Lifecycle approach that focuses on the "service".
I’ll start by reviewing both SDLC and ITIL Lifecycles and then summarize:
SDLC  -  The intent of an SDLC process is to help produce a product that is cost-efficient, effective and of high quality. Once an application is created, the SDLC maps the proper deployment of the software into the live environment. The SDLC methodology usually contains the following stages: Analysis (requirements and design), construction, testing, release and maintenance.  The focus here is on the Software.  Most organizations will use an Agile or Waterfall approach to implement the software through the Software Development Lifecycle.
ITIL  -  is a best practice for IT service management (ITSM) that focuses on aligning IT services with the needs …

Incidents when a Defect is Involved

Question: We currently track defects in a separate system than our ticket management system. With that said, my question is does anyone have suggestions and/or best practices on how to handle incidents when a defect is involved? Should the incident be closed since the defect is being worked on in another defect tracking system if it is noted in the incident ticket? I am considering creating an incident statuses of 'closed-unresolved' so the incident can still be reported on in our ticket management system but know it is being worked on/tracked in the defect system. With defects, it is possible that we may never work on them because they are very low priority and the impact is low to the user. However, in some cases a defect is being worked on. Should we create a problem ticket instead?
Thanks, René W.

Answer: RenĂ©. In ITIL, the activity you are describing is handled by the Problem Management process. ITIL does not use the term “defect” but it does use the term “known error” to…