Skip to content.

TalkBMC

Sections
You are here: Home » Blogs » Wiley Vasquez » Exploring New Ways of Achieving Operational Excellence

Exploring New Ways of Achieving Operational Excellence Exploring New Ways of Achieving Operational Excellence

Document Actions

I certainly didn't wake up Tuesday morning and say "Hey, I am going to do something 'green'."  Nope,  I went about my daily meetings in Houston - quite an exciting and productive day it  was.

 

Twenty four hours before my flight Tuesday evening, I received an email on my Blackberry  giving me the opportunity to check-in online, saving time at the airport do so.  While checking in, I was given the option to print my boarding pass or receive an email with the boarding card.  Since I was doing this from my Blackberry, I was not near a printer (nor am I sure I could've printed to one even if I were - unless there is some plug-in out there that does this).   So naturally I selected for them to email me the boarding pass.  When I did this, I wasn't entirely sure what I was actually doing.  I did this expecting a .PDF file to be emailed to me where I could print it - which I would do when I was in the office for meetings.

 

During one of my meetings that morning, I received an email on my Blackberry with the following:

 

Subject: "Link to mobile boarding pass for your flight to Richmond".

Body: " Please use the link below to retrieve your mobile boarding pass, which must be displayed on your mobile phone or PDA at the security checkpoint and again at the gate to board your flight.

 

[URL link]

 

As a reminder, the mobile boarding pass can only be used at IAH Terminals B, C, and E"

 

That sounds cool.  So at the next meeting break, I quickly opened that emal again and selected the URL link and viola! I was brought to a page that had an odd square looking bar-code and boarding card information.  I thought to myself can this actually be used?

 

Well upon arriving at Terminal B at Houston's IAH airport,I waited in line until my turn.  I pulled out my phone, selected the link and gave it to the security attendant checking ID's.  He said with an eagerness  "Oh Wow! This is my first one!" I responded, "Mine too."  So he grabbed his rather large handheld scanner and started waiving it over my Blackberry.  I tried five or six times.  A gentleman behind me made a comment "I was going to do that too, I'm glad I didn’t".  He wasn't mean, rather was in the tone of not-another-piece-of-too-good-to-be-true-technology-that-doesn't-work.  So I let him go ahead of me.

 

In the time it took for another security attendant to check his ID the security attendant helping me had taken my Blackberry and his scanner and put it in the shade of this podium and it work!  He was so happy - and I was as well.  Things were great.  He even informed me that I did not have to show my boarding pass to the attendant waiting as you walk through the metal detectors.

 

I made my way to the gate thinking, that was pretty cool.  When it was time to board, I pulled out my Blackberry and handed it to the gate agent.  She said almost the same thing as the security agent, "This is my first one!" proudly.  I again responded, "Mine too.".  This time they had a different machine.  It is a stationary scanner attached to their podium.  On her first try it did not work - she seemed to have scanned it to fast.  The second try, she laid the Blackberry on the podium under the scanner and slid it from of the screen to the top slowly.  "Beep!" was heard and smiles on both of our faces signaled all the world was right again.

 

And again I thought to myself, that was cool!  It wasn't until take-off that I started to think about why Continental Airlines would offer this.  I am thinking it most likely had some combination of customer experience and cost savings driving it.  But it hit me like a brick that I actually did something "green" and didn't even know it at the time - I did not print that boarding pass!!  While a tremendously small contribution, it was a liberating and powerful feeling that came over me.  It felt REALLY good!  The inconvenience of it not working perfectly was insignificant now - just as having to take my shoes off to pass through security.

 

If we all make one tremendously small contribution, collectively we will make a tremendously large contribution, a tremendously large difference.

 

While my family and I already recycle, this has had me consciously thinking ever since of new 'green' opportunities I can take advantage of. 

 

I'm hooked and hope you will be too!

 



Saturday, December 08, 2007  |  Permalink |  Comments (1)

Nearly every organization's IT department employs some level of task automation.  And most of the automation was born from system administrator's  great abhorrence for routine drudgery or in pursuit of a talisman to protect them from the increasing workloads brought on by "do more with less" executive directives - both of which are very valid and noble purposes.

 

Unfortunately most automation is in the form of randomly developed scripts - an administrator with the absolute best intentions - writes a script that performs some time saving function.  However most likely the script isn't well documented, may or may not tell others about it,  and does not usually meet any sort of coding standards.  The script may even have potential security risks as it hasn't gone through proper software development controls.  And this practice is probably more prevalent than you may imagine.  

 

OK, so these are some of the 'recreational' practices going on currently in the enterprise, but what are the implications?  It's a fact that whether businesses are trying to cut costs, take on new ventures, grow the business, address regulatory concerns, improve operations or just about any other business initiative, information technology will be used.  There are no signs of the IT proliferation slowing down  especially with the advent of virtualization which enables businesses to do so even faster and with lower cost of capital.  So the risks to the business are only going to increase with the current way automation is being conducted.  We also know that businesses are not interested in increasing IT operational costs, certainly not in-line with current ratios. 

 

In the recreational approach to automation its also most likely true that business continuity is not taken into consideration.  The more an organization becomes automated using these recreational practices, the less possible it becomes to be able to recover from a disaster as the automation has eliminated the manual procedures and there is no one that could even revert these operations in the case of a disaster or business impacting incident.  Automated operations require strict planning.

 

So the implication of not instituting structured automation development and control processes and eradicating the recreational automation practices is a significant increase in risk to business operations.  By conducting a structured program of automation, there is also higher potential of productivity improvement and cost reduction because a systematic method will be used over an ad-hoc method of convenience.

 

An implication of leveraging a professional approach to automation also provides the ability to reduce the dependence and risks associated with off-shoring.  You see, there is a definitive labor cost 'floor'.  Regardless of the country that actually offers the lowest labor costs, there is a bottom and the bottom will continue to rise in that country due to demand for that labor.  We've also seen where demand for this type of labor has sparked significant frenzy for 'job-hopping' in those countries.  This creates another significant problem for operating a stable operation. 

 

Automation when coupled with a stable (and capable) organization, on the other hand, is an ideal solution as it creates characteristics I call CASM²

  • Cost
  • Consistency
  • Accuracy
  • Availability
  • Accountability
  • Speed
  • Scalability
  • Measurability
  • Manageability

 

Automation will increasingly become a fundamental and essential  IT management practice if for no other reason than simply because of the economic driver to do so.    With this desirable business capability, corporations must start to transition out of the current automation practices they find themselves using and to a professionally and 'planned' automation model.

 

To further the discussion and help the transformation from recreational IT, I'll talk about an interesting topic in my next blog entry  - "Does the Automation Team belong in the Application Team or in Operations"? 




_____
tags:
Saturday, December 08, 2007  |  Permalink |  Comments (0)

Was talking with a service automation consultant colleague of mine this week about an engagement he was working on.  The problem being solved was pretty typical in most IT organizations today.    What was eye opening was the cost savings or cost avoidance to be had.

 

The IT environment has exploded in complexity.  I define IT complexity as the diversity, volume, and rate of change.  There is so much to do, and not nearly enough hands, even if you're leveraging low-cost labor strategy. 

 

The net result is lots and lots of tasks that should be done and need to be done, aren't getting done!

 

So my colleague I was talking with was working with a broadband internet provider  whose business was challenged with eliminating false positive support calls going to the Telco when a T1 line was in fact actually OK and not impaired.  BTW,  I am purposefully staying away from the technical details.

 

I asked my colleague if he wouldn't mind working on a mini-cost savings/cost avoidance analysis with me.  Using a very simple publicly available model (see below),  it was determined that by automating that one seemingly minor task, would yield close to $36,000/per month or $432,000/per year savings in productivity!   And this does not even account for the wasted time errant tickets that otherwise would have to be chased down and followed up on.

 

Interestingly, this example is an estimate because the customer was actually unable to provide the number of times this was actually performed during a day - the estimate is based off the number of events seen in the event management system.  It is worth noting that while these actions should have been taken every time, it is highly likely that they were not, due to the volume.

 

Because of the complexity of the IT environment and constrained staff count and labor costs, many customers are not operating their environments effectively.  Many situations like this one are just slipping through the cracks – resulting in inefficient operations and negative business impacts.

 

As you can see, there are savings just waiting to be had.  Service Automation platforms are now more economically viable than ever and will become the preferred method for addressing productivity in IT organizations and IT service providers.

 

There is a definitive floor in terms of labor costs and they will rise over time - automation can be a sustainable solution if taken seriously.  I'll address this in my next entry.

 

Simplistic Model:

 

Number of discrete tasks that are involved in the process

7

Average time to complete each discrete task ( if multiple people  perform their tasks in parallel, add all of their time)

15 min.

Number of times per day task is performed

150

Number of days per month task is performed

30

Cost per hour for that time

$32 total per  hr.

Total Month Savings/Cost Avoidance

$36,000

Total Annual Savings/Cost Avoidance

$432,000



_____
tags:
Tuesday, October 30, 2007  |  Permalink |  Comments (3)
This will be a quick entry to hopefully spawn discussion.

Many of the organizations that I've met with in the last 12 months still do not have roadmaps for operational improvement of IT.  It seems company's are still taking a disconnected approach to improvement efforts. But now instead of the technology silo's that were once put forth as the poster child for bad behavior, now it is process silo's!

I see incident management process projects going on without consideration for how they integrate with other processes.  And its not just that the issues are not being addressed in the same project, its that there is not even a plan for how they will come together.

A roadmap should contain an integrated Process, People/Organization, Technology, and a Financial projections laid out in a multi-phased program.  With an integrated plan, you are far more likely to be successful for the simple fact that more is accounted for. 

The Roadmap essentially becomes your3-5 yr. business plan that you use to get buy-in from the business and as a communication tool for the organization.

I'd be interested in hearing from you as to whether your organization has a Roadmap as outlined above and if you don't have one the reason for this, why that is.


Next up on the blog will be the topic of Automation!




Wednesday, October 24, 2007  |  Permalink |  Comments (0)
Defining a vision is one of the first key steps in progressing your operational performance.  However, envisioning a new day can be difficult.  Yet is fundamental to progress, so it is worth understanding different ways to do it.

Consider when Thomas Paine sat down to write 'Common Sense' in 1776 during the American Revolution.  His ideas and vision drew out the direction for a new and possible life and rallied an entire group of people into action.  It was the precursor to a new design for an entire nation.  Can't help to wonder if he were to see the nation today, would this be what he envisioned?

Or perhaps consider what Dwight D. Eisenhower had in mind for the Interstate Highways.  Could it not be seen that there would be large trucks for commerce?  Why did he not envision a separate network of highways built solely for commerce?  Why did he not anticipate the overwhelming demand for suburban life around key cities that would drive the need for automobiles?  

Granted these two examples are most likely not comparable in complexity and scale as most of our projects.  But they highlight the importance of vision as an enabler to progress.  And vision too is a process that must be revisited.

Sometimes looking at the same thing from a different perspective opens whole new understandings.

The traditional method for envisioning success is to stand in the present and try to look into the future.  It is often hard to do this because you are mentally constrained from all of the things you are aware of and instead this method frequently turns into an exercise in figuring out how to get around barriers.

Instead how about trying an alternative method - Try to stand in the future and looking back.

Wouldn't it be interesting to put yourself in the future (say even 3 or 5 years out) as a columnist or analyst and write a front page article about your company?  And maybe how it compares to the competition.

While this method has been around a long time I find it rarely practiced on IT operational performance improvement projects.  Thinking in this way might be easier for you to start to picture a new day.  You can even think about some of the details using this same method.  

This then sets the stage for a very productive design phase.  Often times as you try this method, and move into the design phase, you'll start to see relationships and inter-dependencies better as the scope becomes clearer.

So, the next time someone asks you 'What does success look like to you?' for your program or project, you'll be able to answer that question with confidence and clarity.



_____
tags:
Saturday, July 14, 2007  |  Permalink |  Comments (0)

In recent customer discussions and projects I've seen an interesting focus on the process flow (a.k.a. work flow) aspects of process operation and yet little work on the organizational, process governance, and process performance (output and outcome) aspects.

Broad stroked characterizations can turn into oversight of very important areas.  For example, I've witnessed numerous projects where companies are 'implementing ITIL' that ITIL is 'about processes'.  Then the projects they have embarked on is really just digitizing their existing work flow with maybe some minor tweaks, and training their staff on ITIL foundations.

You may not know this, but best practices process flows exist.  Yep, you can actually buy them.  BMC for example sells a new product called BMC Service Management Process Model (SMPM)  http://www.smpm.info/.  It is a set of best practices used in nearly two hundred implementations world-wide.  It comes complete with roles and even detailed work instructions.  And it works with Remedy ITSM v7 to provide pre-defined, integrated process flows, roles, and work instructions right into the product.  And it fully leverages ITIL's best practice guidance.

What this means to you beyond taking the risk out of your process design, is the significant reduction in your process flow design time and costs, so there is significant benefits to taking this approach.  However, process operation is a change in the way management is approached, not only just a change in process flow and the enabling technology.  Implementing process without the proper process governance is a process that is bound to 'snap' back or be circumvented.  Is the process delivering what it needs to, to satisfy customers?  Is it running as efficient as it was planned too?  So just how many incidents did we think we could handle in day with our current staff?  Is the external service provider that is part of the process performing to the levels needed?  Have the people identified as 'process owners' actually equipped with the tools and training that they need to be able to govern the process?

And what about KPI's?  There are volumes filled with KPIs - but have you noticed that they never tell you what data stores they should pull the data from, what tools to use, what other KPI's they need to be coupled with, what actions should be taken when an indicator goes up/down or stays the same?

What about the organization?  Is it good enough to assign a person to a role? Might there need to be some structural changes that may be needed?  Are the right people in the roles?  And is the organization ready to change to a new process, tools, and accountability?  Who is and who isn't ready and able to change?

What about process performance?  Did we actually sit down and try to determine how many changes of a certain type that we need to be able to handle based on our business' requirements?

And I've purposefully stayed away from services - such as what services do we need to deliver to the business, what do the levels of service need to be, and how the processes need to perform to deliver those services.

And these are just things off the top, there are additional critical areas involved with 'Process'.

When embarking on your process efforts, I encourage you to think more broadly about what 'process' means.



_____
tags:
Wednesday, July 11, 2007  |  Permalink |  Comments (0)


Internal 'customers' are said to be the people in your company or perhaps a partner that you provide your services too in order to deliver your company's products or services.  External customers are said to be those people that actually buy your company's products or services.  These are certainly cute and clever definitions.  

But let's clear the fog - there is only one "customer" - the people that actually buy products and services from your company and which your company derives revenues!

When I hear "Run IT like a Business" I can't help but cringe.  It has way too much room for interpretation, and given the creative minds that are in IT, just about every interpretation has been tried.  We really do not want to run IT like a business, rather 'run IT with business discipline' is probably a more appropriate phrasing.

Why don't we want to run IT like a business?  There are many reasons - the first being does your business really want/need IT to be run like a business?  After all, business is run for profit with targeted margins and there are marketing activities to drive revenue.  Those alone are big enough reasons your company probably doesn't really want to run IT like a business, but does want it run with responsible business discipline and practices.

But even more dangerously, I've seen many company's IT organizations talking about their 'customer', meaning internal customers.  This way of thinking and worse, operating, causes many undue problems and unproductive activities.  Situations stemming from statements such as 'the customer is always right' is a common one in addition to very wasteful pampering.

Anyone that you work with in the overall delivery (e.g. design, development, manufacturing, distribution, marketing, sale, etc.) of a product or service that the company sells, is a co-worker.  Whether they be an actual employee, contractor, or partner.  And as such the mission and focus should be on the customer that buys the products or services.  Co-workers should treat each other with professional respect, courtesy, and do so in a pleasant and productive manner.

Alignment happens at the customer


By each organization within the company focused on the real customer and actually working together toward that end and not spending cycles trying to 'satisfy' each other through fictitious role playing, every part of the organization will bring its best to the process and all parts of the company will naturally begin to align.  

This 'our customer' view is as much, if not more, an ideology change as an operational change, and doing it will yield many productive benefits.

_____
tags:
Wednesday, June 06, 2007  |  Permalink |  Comments (0)

Go to Wikipedia or just about any search engine and search on "operating system" and you get a description or link   “…an operating system is a set of computer programs…”.  This is obviously an indicator of the technologist’s view of the world.  But that aside, a computer operating system is a well-defined set of operating functions working in coordination that software applications run ‘on top’ of.  So it is no surprise that computer operating systems use terms such as a “processes” (Linux/Unix uses) and “services” (Windows), to describe these functions and their interactions.

If you understand the ITIL practices, that is essentially what it advocates.  The difference is that the ITIL takes a far broader scope to include people, process, technology, and management all working together in a well-defined, designed, and planned manner.

Does this mean we could be heading toward ‘versioning’ our organization themselves -   ABC Co. Version 2.1?  If we look far enough out, it is not unthinkable.  Comprehensive and clearly defined processes and services, well-understood and defined job roles, appropriately applied skills, and organizational performance management are some of the key components that will need to be in place and an uber controlled operation could itself be version controlled…! 

You may be saying to yourself ‘we already do those things’.  Indeed, but consider this – if you view your organization holistically (people, process, technology, management) as an operating system, what level of quality of an operating system would it be?    Note - there is a marked difference between a designed operation and an operation that has organically adapted based intuition.

“Help Wanted: Operations Architects”

Like most IT organizations, does your architecture team primarily focus on technology-related responsibility?  If so, then who has the responsibility of looking at your IT organization as an operating system and what are their skills?  Perhaps you have process owners or process managers.  While these roles are necessary, a common gap in many IT organizations is an ‘Operations Architecting’ function.  Frequently the function is fragmented across many different roles in a passive and disconnected fashion.

Operations architecting is responsible for designing/defining the processes, skills, technologies and automation, policies, agreements, measurements, etc.  This will take a new set of architecture skills than what exist in most organizations today.  While there are some of these skills in the market, they are largely rare and highly sought after and come mostly via consultants.  These offerings are some of the highest valued IT business services.  I should point out, just because someone is ITIL Service Manager certified, does not make them capable of architecting IT operations.  Many other skills are required.

Many companies have started on their IT improvement programs and have identified one or more processes to start on.  Whether you have started or not, it is worth taking time to ask the question “What would a successful operating system look like to our business?”  A good architect or more realistically, an architecture team, would be able to capture the requirements, and design the to-be operating system, and plans to get there.   When answering the question, a good architect also always keeps in mind the various interests involved – customers, employees, the business, investors, regulators, etc.

Okay, so what if during the design you determined outsourcing was a requirement in your plan?  Particularly important in multi-sourcing arrangements where there are multiple service providers, is the need for Operations Architecting.  To help answering the questions such as “Exactly how will the DBA outsourcing provider know not to respond to that alarm at 2am when it is just a scheduled change outage by the application outsourcing provider?”  As you can see, these processes will need to be designed accordingly, the people, processes, policies, etc. all need to be considered and accounted for.

I hope this view of looking at IT operations more holistically helps put a frame around your improvement program efforts and highlights some of the critical skills that you’ll want to employ. 

In the next entry, we’ll talk about the various BSM starting points and why.   We’ll discuss some real-world projects and I think you’ll find the decisions to start in one area versus another quite interesting.



_____
tags:
Tuesday, May 29, 2007  |  Permalink |  Comments (0)
Don't Forget the Technology Administration Processes (TAP)

On my next entry I will discuss an interesting organizational unit that is missing in most IT organizations that would address the problems discussed here.

There has been a tremendous amount of press around ITIL and Service Management. And in actual customer engagements there is a lot of focus on the cross-organizational processes. Unquestionably this is all vitally important, but we should not forget the tremendous opportunities for efficiency and quality gains awaiting in the Technology Administration Processes (TAP).

The actual quality of an IT service (for example: an ERP Application) requires a many different technology organizational groups to be involved - database administrators (possibly some on dbms' such as a DBA for Oracle, a DBA for SQL Server), system administrators (possibly a Unix administrator, Windows Administrator), Middleware Administrator, Storage Administrator, Application Support, Vendor Support, Web Infrastructure Support, etc.

IT Service management sets out to make the IT organization more efficient, provide better quality, and make sure IT is doing the things the business needs them to be doing in the boundaries the business dictates. ITIL focuses on some of the big cross-organizational processes, the integration of those processes, and the management of those processes.

The majority of the actual activities IT performs is technical in nature and arguably forms a significant basis for operational improvement opportunity.

Preventive Maintenance Process

Preventive Maintenance is a boring, old, tired, industrial type term and certainly not as flashy as some of the marketing terms for reactionary activities. Yet it is these very processes that are at the heart for the revenue and productivity to continue flowing for companies.

Having the opportunity to visit with many companies, it is still surprising to find many technology administration teams don't have a documented and rigorous 'Preventive Maintenance' process. They do perform some of these functions, but it is more on an ad-hoc basis or at best on a habitual basis.

And yet these companies are still focusing a lot of resources on break/fix and Incident Management processes...

Duplication

How many times have you seen where a Unix administration team and a Windows administration team do the exact same tasks - file system maintenance, backups, security reviews, etc. etc., yet don't share any of the processes, information, tools/automation with each other? And usually one group is viewed more highly than the other. "Those guys have their stuff together" is a common comment I hear that is a key clue that there are opportunities for quality and efficiency improvements.

What's happening?

These are seemingly intuitive tasks that you would expect any IT organization to be performing, but aren't. But, why aren't they?

In organizations where you do see these processes, you'll find at some point a manager or leader that has had a background in mainframe operations, or has come from a managed services provider, or even has worked in a manufacturing operation. Of course this is not always the case, but it has been a general observation of mine over the years.

Also, the educational system does not provide sufficient 'operational' focus as much as a focus on being a technologist. As such the vast majority of people in IT (including management) are interested and skilled in the technology of IT and not on the operations of IT. Further these tend to typically be the more creative-types and not so much the care-giver or factory types.

The creative types tend to bore quickly with mundane tasks and want to move into the next big project. Sowing their oats is far more interesting to them than being paternal tasks!

It is the responsibility of the managers of the technology administration teams to work to achieve the right balance of creative and care-giver skills within their teams. Today it is clear that in most IT organizations the balance still favors the creative types.

As service quality and efficiency become more important to a company, preventive maintenance processes and care-giver types must become a larger component of your overall service delivery capability.



_____
tags:
Wednesday, March 07, 2007  |  Permalink |  Comments (0)
IT organizations being a creative and resourceful bunch, have been integrating IT management technologies together in innovative ways forever.  These custom solutions have been very valuable but typically difficult to support.  Now these solution 'mash-ups' are starting to be made available as On Demand and Managed Services.

Here at BMC UserWorld 2006 discussions have yielded some interesting ideas both on the user side and partner side as well.  One of which can probably best be described as 'role-based solutions' - a package of management technologies that are geared specifically to assist an IT user perform their complete job more effectively.   This package is then offered in an On Demand model.

For example: Through the course of their duties an IT service desk analyst performs a variety of activities - communicate with their internal customers, log tickets, triage, etc.  And often they either don't the correct solution set or have a fragmented grouping of self-developed tools, tools from a variety of vendors that are difficult to manage. 
With a role-based solution, the service analyst would get all the tools they need - a service desk product, instant messaging product, remote control product, variety of troubleshooting automation tools, etc. all packaged together and delivered as a 'single' application in an On Demand fashion from a single provider.

This is surely to be an interesting area to follow and I will update you with more on this topic as we go forward. 

I'd love to hear your thoughts on this as well!

Wiley






_____
tags:
Friday, September 01, 2006  |  Permalink |  Comments (0)
Wiley Vasquez

Subscribe to Wiley's blog Subscribe to Wiley's blog

Bio

Email Alert: Wiley's Blog

Get an email alert when I publish a new blog! Enter your email address:

 

Powered by Plone

This site conforms to the following standards: