May 2008


Technical staff can often be the worst at this - but how often has the comment: “who reads the manual?” been heard? That is a mistake. I have seen many instances where a need exists for a particular technology asset, either hardware, software or both. With the best of intentions, a solution is identified, and a few more dollars leak out of your A/P.

Have you looked to see if you already have something that will do the job? If the manuals for existing tools had been read - you might find that the capability to perform that task already exists.

This article on Managing Inventory for Profitability by Ellen DePasquale at Inc.com demonstrates that many accounting packages can already deal with inventory management. Ditto for Purchasing Managemement.

An Asset Management system I have used did a reasonable job of performing Help Desk management as well. And in a fairly extreme case, Captain D. Michael Abrashoff Author of; It’s Your Ship: Management Techniques From The Best Damn Ship In The Navy (see The Bookshelf) Describes a communications rating who actually read the manual and identified a key communication system that no one knew existed.

So you may already have something that will do the job.

The Title of this is directly from the reference below, I will also admit; I don’t Like maintaining E-Mail servers.

It is true - E-mail is still a critical element for my organization, and many others. But I do not like the time required to keep these complex beasts running. And like a flighty thoroughbred - they have their eccentricities.

This Information Week (Canada) article called; Yes, it’s time to destroy your e-mail servers (I stole the title!) puts it quite succinctly.

Two more articles, one from Rob Preston at Informationweek.com he quotes;

…Capossela predicts that half of Exchange users will get their e-mail from the cloud within five years.

Another from microsoft-watch.com References the same interview - but says 5 years will be too late.

It is not always wine and roses though. We used to utilize hosted E-mail, but then returned it in-house for two reasons. One reason was that we have a fairly complex E-mail environment and utilize some of the extended collaboration features of Microsoft Exchange Server. We probably could have developed a work around for this one.

The second one was more difficult; and so far I have only seen one press mention of it. As this CIO Magazine article states;

To be sure, it’s still the early days of cloud computing. Concerns (exist) around security and application latency…

This last quote is what caused our problems and deserves a little more detailed look. The term “latency” can be defined as the time taken for a packet of data to be sent by an application, travel and be received by another application. Now this little term can more complex than it sounds.

As an analogy, if you are driving 40 miles, at 40 miles per hour, we can automatically assume that we know how long this journey will take. And assuming you were on an empty highway with the cruise control on - we could be right.

However, if that 40 miles is across town and includes stop signs, traffic lights, some toll roads, merging lanes and all of the slowdowns that we can have driving, we can no longer assume how long our journey will take. Network connections are like that cross-town journey. Every router, switch, firewall, traffic shaping device and other tools used on the network all act like those stop lights, and merge lanes, each one slightly slowing down that traffic journey.

If you have ever opened an E-mail on a Web mail service such as Hotmail or GMail and then tried to view that new 1 Mb baby picture you were sent - you see what a time consuming exercise that can be. Now imagine it with a 10 Mb Power Point deck or Adobe PDF document.

Then imagine that you emailed that 10 Mb power point presentation to all 10 members of a project team - and all 10 start to look at it roughly at the same time. 10 Mb x 10 people downloading it to their PC is 100 Mb of data that you are squishing through your internet connection. The time it takes to open that E-mail will degrade even farther.

That is what killed hosted email for us, like most businesses in the SMB space, we cannot afford an infinitely huge “pipe” to the Internet, and as we deal with large media and Adobe PDF files, many of which are E-mailed, We found that during peak periods, it had reached the point that opening an email with an attachement had to be done beore you went to lunch - you hoped it would be finished when you got back.

I mean figuratively of course. As stated in my post on Outsourcing; complexity causes instability, instability causes breakage, and breakage causes downtime and costs money.

And my recent post about using IT Vision to ensure that you have planning in your IT environment to avoid the IT equivelent of “urban sprawl”

An acquaintence in the IT field pointed me to a particular SMB IT “administrator” job advertisement - Some of the requirements are fairly standard - but many of them compete in their own areas - and they all require “extensive” experience.

First point; with so many technologies in use, “extensive” experience in all of them? forget it - the old adage of “jack of all trades - master of none” is more like it. and since many of the technologies are security related - that is not something I recommend.

Second point; the below list of skills could suit a larger organization that has grown through M&A, but in the SMB space, complexity causes instability, instability causes breakage, and breakage causes downtime and costs money.

So many of these products overlap and compete with each other that you can guess that there was no long term, strategic IT vision as this organization matured. Point solutions, or what someone thought was “cool” for the day was used. To be fair, I don’t personally know the company or the location - so they could be trying to rein in this sprawl in the future, but the cost in time and money doing it will be difficult.

This is not to say that there is anything wrong with any of these technologies and products, my point is that for an SMB - there are just too many of them. Many of the individual technologies below can be a full time job in themselves.

Look at this laundry list ‘o skills; (This is just a summary)

Certifications in Novell and MCSE

Minimum ITIL Foundation an asset

Extensive technical knowledge LAN, WAN, frame relay, xDSL, TCP/IP, ATM, T1, 802.11x, SLP, NCP
Extensive client/server and operating system experience with Microsoft and Novell and Suse Linux
Knowledge of Symantec END Point server and workstation anti-virus software, Check Point, Symantec Endpoint, Windows firewalls, Radius authentication services and intrusion detection systems
Knowledge of MS Server 2003 and Active Directory, MS Exchange Novell OES GroupWise and ZenWorks.
Extensive experience in developing and managing Windows Active Directory OU Structures and Group Policies.
Extensive experience with Novell eDirectory.
Extensive experience with Novell Zenworks for application deployment, patch management, and data collection.

Plus “knowledge” of H P OpenView and Cisco Works, Wireless technology, MS Exchange 2003, Citrix Metaframe, and the list goes on

Several weeks ago our Software Development Manager took the time to review all database’s and software applications for orphan user ID’s. He found some. These user ID’s were people no longer employed with us, in some cases customer accounts that had wanted to view some “pre-release” version of something years ago. All these accounts were very old and pre-dated both of us.

Still, this should never happen - processes should be in place to ensure that old accounts are removed immediately upon either change in a resources role, or upon their leaving the organization.

This eweek.com article by Brian Prince quotes;

The article also references the recent LendingTree data breach, where former employees gave away their login ID’s - these ID’s had never been canceled.

In this time of Software as a Service, (SaaS) this can be even more critical. If you leave old employees accounts active within a database or tool on your network, they still have to get access to the network to utilize the account - with Software as a service - they can do it anywhere in the world. An orphan login account in a hosted tool could enable a former employee to retrieve every sales account and phone number you have.

As a SMB business manager, I am sure you have had to deal somewhat with vision. Perhaps for an elevator pitch for VC capital, maybe for an IPO prospectus. Maybe even just so that your customers know what you actually do.

Do you have an IT vision as well?

You should.

This vision should be a lesson in simplicity, it should have no jargon or technobabble. But it should be a clearly articulated road map for the future. And yes, it should be revisited regularly. Now this vision will not be as complex or tough to build as the vision required for some change initiative, but it should exist and be articulated and communicated by senior IT staff as required.

As a post I did here states, complexity causes instability, instability causes breakage, and breakage causes downtime and costs money. Simply put, this vision will articulate what technology platforms and tools your business is going to utilize. And it should be the road map that limits this complexity.

Unfortunately, in the SMB space, we often find IT complexity that is completely beyond the bounds of reason for our organization sizes. By complexity, I mean technology sprawl. There is absolutely no reason for the average SMB to have more different kinds of technologies, tools and architectures than a company of IBM’s size has.

That may be exaggerating - but it happens all too often. A year or so ago, I remember speaking to an IT Manager at an SMB sized organization that had several facilities and a good customer base spread along a couple of lines of business. This business was using three different database management systems, four or five different classes of server operating systems, and several different tools that actually performed the same function for different operating units.

Consider just the direct upfront licencing costs of all of this software and hardware, Now consider the expertise and time required in the care, feeding and maintenance of all of these. And we will avoid even considering that a customer of two business units will have separate customer records from different tools each unit uses.

This organization did not have an articulated IT vision. So one business unit manager wanted a particular tool that happens to run on MS WIndows Server and MS SQL Server, while another business manager wanted a similar tool that ran on Linux and Oracle Corporations Database Software. And a third enterprise tool ran on a Novell server etc etc.

Your technology road map vision may be partially dictated by customer or supplier linkages, or you may be lucky and can define it the way you prefer from the ground up. The important thing is to define it. Regardless of which architecture and platforms you choose, emphasizing that these are the corporate standards will reduce the costs associated with end less sprawl.

Will there be deviations? possibly. But you can demand a good business case to support it.

A May 12 article in Information Week by Michael Biddick brings up one nugget that is applicable to the small / mid market space. (technobabble alert - the above article is geared towards Enterprise IT Managers, if you are a general business manager in the SMB space, it will be a little,,,,,, dry!)

While ITIL is becoming the de facto standard for enterprises, we’ve seen too many organizations that just send their people through a class and expect the world to change.

It is worth repeating, ITIL is a journey - not a destination. It is people and processes. It requires commitment and management. There will not be a time when you can say “We are finished”.

I have been in the technolgy business for quite a while. In this business - the ability to ensure that all your business data is backed up and recoverable should there be a failure of any kind is always top of mind.

I had an incident recently that had me thinking back at data recovery over the years (sort of mental doodling!)- and unfortunately some “non” recoverable data as well. One memory that has stuck with me; Many years ago I worked with a software development outfit that had a small business service tool that was still good old MS DOS based. Backing up the data was through a menu option and just needed a good old 3.5 inch floppy disk.

One thing that you must know - magnetic media does not last forever. No matter how often we communicated that, there were customers that backed up their data to the same floppy disk for years. And never knowing at what point that the little floppy had finally died. In one case, we looked at this old floppy disk that looked it had been run over by a truck. It had been carefully loaded into the floppy drive for who knows how many years. The time came that the data needed to be restored….. well it was dead.

Today you will be using a tape drive of some sort for your backups. A question though - do you know how old those tapes are? have you ever tried restoring data from them? If you can’t answer those two questions, a little investigation is in order. (I try to utilize tape tape media for only one year before it is retired)

I always recommend a 4 week tape rotation with weekly and monthly off site storage for businesses in the SMB space. (Although there are more and more online storage services coming around, I have not tried them - maybe a future post)

The final piece though - have you considered what type of tape hardware that you are actually backing up with ?

If you are like many, you probably have old Vinyl LP records hanging around, Maybe some 8-Track cassettes hiding somewhere, how about 8mm movies? Next question - Can you play them on anything still?

The hardware creating those backups does not last forever either - like 8 Track players, once your oldie dies all the tapes are useless. As an IT Manager I agree that it is a challenge to convince my boss of this. It is like insurance! - You hope you won’t need it; Until you do need it!

Like insurance, having a second piece of identical backup hardware can pay dividends if the “oldie” decides that life is to difficult and self destructs.

In short;

Your tape media has a life span - replace it
Your backups need to be tested by doing data restores periodically
Your backup hardware is not going to last forever either - plan for it!

I Recently read Outsmart!: How to Do What Your Competitors Can’t by James Champy. (See The Bookshelf) Along with Michael Hammer, Mr. Champy is the best selling author of Reengineering the Corporation: A Manifesto for Business Revolution

If you are sick of the status quo - or are looking at your own business start up ideas, definately worth reading. The chapters of the book cover businesses that looked at the customer, and through reframing the customer experience, improved the the product / service delivered to provide increased value. The epilogue then dives into some of the concepts that Mr. Champy identifies through his research as the keys to the value that they have created. And none of these organizations started as Fortune sized companies either.

As Mr. Champy states one of these keys;

” … focus on how they can better serve their customers, incumbent companies focus on their competitors

I have done several posts on this blog about the fact that it is the customer that pays the bills . And there is also an excellent comment thread on the Small Biz Survival Blog on reframing the way you deal with your customers. The post and reference in the link deals with professional wedding photography. In this day of Digital Cameras every where, how is a professional photographer to make a buck? the comments go from providing professional photography training, to online portals where the amateurs can also submit their photos’s for other members of the party to choose and print.

Good stuff - Although no one says it is easy

The next piece for ITIL in the small business / medium business space covers Problem Management. Again, this will be a quick summary of some key points. As I stated in the earlier posts, all of the ITIL processes are tightly linked, as each process generally accepts information from, and provides information to, the others. However pieces can be lifted and customized for your environment. Again, the goal here is to demonstrate how the basics of ITIL can assist organizations of all sizes reduce costs.

As mentioned in the previous post on Incident Management. The ITIL Incident Management process and Problem Management process can seem to be the similar at first glance, however there are key differences; Incidents are deviations from expected operations, and Problems are the root cause of those deviations.

An incident can be any IT related issue such as; “Can’t log in”, “No E-Mail”, “Can’t Print” etc. The tendency for internal or external IT staff is to simply fix that service incident - “There now you can print….” without looking at the underlying root problem. These root problems can be an important source of information.

To use a non technical example; A customer of yours complains that they did not receive their proper order. This would be an Incident. You then re-send the proper product, the Incident is now closed - the customer has their order.

I don’t know about you, but I see something missing here. Why did the customer not receive their order? This “why” is the Problem. or root cause of the incident. You investigate and you find out that the packing staff boxed the incorrect order. Now we have documented that we understand the root cause, or the Problem that led to the incident. If you receive 4 complaints in a month that customers did not receive their proper order, and all 4 times it was the packing staff boxed the incorrect order, you now have actionable information to rectify the issue.

Documenting these root cause problems also enables the build up of a knowledge base of Known Issues, or Known Errors that also assist in reducing the the time required to rectify these incidents when they occur.

Again using my non-technical analogy, One incident of a customer not receiving their order is investigated. It is identified that the customer has two logistics centers and will only accept delivery from you at one of the centers. Unfortunately, you delivered to the other one. You now have “knowledge base” information, the next order for that customer you can remind staff that the shipment must be delivered the correct logistics center.

The same concept holds in your technology infrastructure. Here is a technology example I had to deal with. We were using a hardware and software based fax system that allowed our employees to send faxes right from their desktops. These faxes dealt with confirmations for training and are time sensitive and critical enough to cause significant disruption if they fail.

Incident 1: Employee couldn’t fax. I found that the fax hardware had crashed. I also could not figure out why. (OK, no one is perfect!) So I reset the fax hardware, which fixed the incident, and had to set the Problem as an unknown issue with the hardware fax devices. Maybe it was a one time issue.

Incident 2: Employee couldn’t fax (again) - I could simply have repeated reseting the fax hardware, it would have resolved the incident, but it would not do nothing to resolve the root cause problem. So it would just keep happening, it would keep causing incidents, and keep causing costly downtime. (again these faxes were time sensitive) Further investigation and testing finally revealed that the Problem was due to my region moving from 7 digit to 10 digit local area phone dialing. Dialing just 7 digits not only failed to send that one fax, it brought down the fax hardware. This knowledge base information allowed me to provide more training (use 10 digits) and if another incident did occur, the resolution was easy and quick. No further research required.

Utilized with Incident management, an effective Problem Management process provides the following benefits;

a) Identify the root cause. Allowing the root cause to be fixed so it does not re-occur, or documented as a known issue.
b) The known issues have their work-around or methods to solve quickly, without extensive research required.
c) More pro-active prevention of further incidents. Possibly identifying process weaknesses or devices that are failing and should be replaced.

These benefits can reduce costs by reducing the amount of time that your staff cannot produce through failure of some IT component, and reduce the time and cost of rectifying incidents as they occur.

If your small to mid-market business is manufacturing or e-commerce based and you can serve or ship to customers all over the world, great! However if your business has geographical or other boundaries - your web store front should say it!

Web search engines cannot decipher if you have have delivery or service restrictions. They just match words. Now this comes from a recent experience; I was looking for a particular service in my area, I did the usual web search, and received a motley collection of links. One link was a company that does that service. But then I had to drill down into the Contact Us page and found that the telephone number was not even in my area code - (I am in Ottawa Ontario, not Ottawa KS)

The next link found a company that was at least in my area code. However It was not until I called them that I found that they were at the extreme opposite end of the area code boundary. I live in the extreme east end of the boundary, they are located at the extreme west end. So they do not service my area.

Well, say it!

If your capabilities are limited, whether regional, national, or even continental, explicitly state that on your web site. As I wrote here, make sure that finding your location or contact information is dead easy - and that should include a “Serving the….” and the applicable region you that you serve.

Next Page »