Have we really thought about disaster recovery?

by Frank 29. July 2012 06:00

The greatest knowledge-loss disaster I can think of was the destruction of the great library of Alexandria by fire around 642 AD. This was the world’s largest and most complete store of knowledge at the time and it was almost totally destroyed. It would take over a thousand years for mankind to rediscover and regain the knowledge that went up in smoke and to this day we still don’t think we have recovered or re-discovered a lot of what was lost. It was an unmitigated disaster for mankind because nearly all of Alexandria’s records were flammable and most were irreplaceable.

By contrast, we still have far older records from ancient peoples like the Egyptians of five-thousand years ago because they carved their records in stone, a far more durable material.

How durable and protected are your vital records?

I mentioned vital records because disaster recovery is really all about protecting your vital records.  If you are a business a vital record is any record without which your business could not run. For the rest of us a vital record is irreplaceable knowledge or memories. I bet the first thing you grab when fire or flood threatens your home is the family photo album or, in this day and age, the home computer or iPad or backup drive.

In 1996 I presented a paper to the records management society titled “Using technology as a surrogate for managing and capturing vital paper based records.” The technology references are now both quaint and out-of-date but the message is still valid. You need to use the most appropriate technology and processes to protect your vital records.

Interestingly, the challenges today are far greater than they were in 1996 because of the ubiquitous ‘Cloud’.  If you are using Google Docs or Office 365 or even Apple iCloud who do you think is protecting your vital records? Have you heard the term ‘outage’? Would you leave your children with a stranger, especially a stranger who doesn’t even tell you the physical location of your children? A stranger who is liable to say, “Sorry, it appears that your children are missing but under our agreement I accept no liability.” Have you ever read the standard terms and conditions of your Cloud provider? What are your rights if your vital records just disappear? Where are your children right now?

Some challenges are surprisingly no different because we are still producing a large proportion of our vital records in paper. Apart from its major flaws of being highly flammable and subject to water damage paper is in fact an excellent medium for the long term preservation of vital records because we don’t need technology to read it; we may say paper is technology agnostic.

By contrast, all forms of electronic or optical storage are strictly technology dependent. What good is that ten year old DAT tape if you no longer have the Pentium compute, SCSI card, cable and Windows 95 drivers to read it? Have you moved your vital records to new technology lately?

And now to the old bugbear (a persistent problem or source of annoyance), a backup is not disaster recovery. If your IT manager tells you that you are OK because he takes backups you should smack him with your heaviest notebook, (not the iPad, the iPad is too light and definitely not with the Samsung tablet, it is too fragile).

I have written about what disaster recovery really involves and described our disaster recovery services so I won’t repeat it here, I have just provided the link so you can read at your leisure.

Suffice to say, the objective of any disaster recovery process is to ensure that you can keep running your business or life with only a minimal disruption regardless of the type or scale of the disaster.

I am willing to bet that ninety-percent of homes and businesses are unprepared and cannot in any way guarantee that they could continue to run their business or home after a major disaster.

We don’t need to look as far back as 642 AD and the Alexandria Library fire for pertinent examples. How about the tsunami in Japan in 2011? Over 200,000 homes totally destroyed and countless business premises wiped from the face of the earth. Tsunamis, earthquakes, floods, fire and wars are all very real dangers no matter where you live.

However, it isn’t just natural disasters you need to be wary of. A recent study published by EMC Corporation offers a look at how companies in Japan and Asia Pacific deal with disaster recovery. According to the study, the top three causes of data loss and downtime are hardware failure (60%), data corruption (47%), and loss of power (44%).

The study also goes on to analyse how companies are managing backups and concludes, “For all the differences inherent to how countries in the Asia Pacific region deal with their data, there is at least one similarity with the rest of the world: Companies are faced with an increasing amount of data to move within the same backup windows. Many businesses in the region, though, still rely on tape backup systems (38%) or CD-ROMs (38%). On this front, the study found that many businesses (53%) have plans to migrate from tape to a faster medium in order to improve the efficiencies of their data backup and recovery.”

It concludes by estimating where backups are actually stored, “The predominant response is to store offsite data at another company-owned location within the same country (58%), which is followed by at a “third-party site” within the same country.”

I certainly wouldn’t be relying on tape as my only recovery medium and neither would I be relying on data and systems stored at the same site or at an employee’s house. Duplication and separation are the two key principles together with proven and regularly tested processes.

I recently spoke to an IT manager who wasn’t sure what his backup (we didn’t get to disaster recovery) processes were. That was bad enough but when he found out it seemed that they took a full backup once a month and then incremental backups every day and he had not tested the recovery process in years. I sincerely hope that he has somewhere to run and hide when and if his company ever suffers a disaster.

In a nutshell, disaster recovery is all about being able to get up and running again in as short a time as possible even if your building burns to the ground. That in fact is the acid test of any disaster recovery plan. That is, ask your IT manager, “If this building burns down Thursday explain to me how we will be up and operating again on Friday morning.”

If his answer doesn’t fill you with confidence then you do not have a disaster recovery plan.

 

What is a ‘Prescriptive’ RFQ/RFP and why is it bad?

by Frank 22. July 2012 06:02

Twenty years ago our main way of competing for business was to respond to Request For Quotes (RFQ) and Request For Proposals (RFP). Our sales people and technical people spend months on end laboriously responding to detailed questionnaires and spread sheets with only a small chance of winning because of the number of vendors invited to respond. Luckily, this is no longer the main way we compete for business and we now complete only a fraction of the RFQ/RFPs we used to; much to the relief of my hard working sales and pre-sales staff.

Now we only respond to RFQs and RFPs if we have prior engagement plus the opportunity for questions and engagement during the process together with a good fit for our software and services (we sell information management software and services). We also heavily qualify every opportunity and the first step is to initially speed read and scan all proposal documents for what we call ‘road blocks’.

Road blocks are contractual conditions, usually mandatory ones, which would automatically disqualify us from responding. Sometimes these are totally unfair, one-sided and non-commercial contractual conditions and sometimes they are mandatory features we don’t have and often, the road block is simply the prescriptive nature of the request document.

By prescriptive I mean that the request document is spelling out in detail exactly how the solution should work down to the level of screen design, architecture and keystrokes. In most cases prescriptive requests are the result of the author’s experience with or preference for another product.

As we produce a ‘shrink-wrapped’ or ‘off-the-shelf’ product, the RecFind 6 suite, we aren’t able to change the way it looks and works and nor can we change the architecture. In almost every case we could solve the business problem but not in the exact way specified by the author. Because our product RecFind 6 is highly configurable and very flexible we can solve almost any information management or business process management problem but in our particular way with our unique architecture and our unique look and feel.

In the old days we may have tried to enter into a dialog with the client to see if our solution, although working differently to the way the author envisioned a solution working, would be acceptable.  The usual answer was, “Why don’t you propose your solution and then we will decide.” Sometimes we did respond and then learned to our chagrin that our response was rejected because it didn’t meet some of the prescriptive requirements. Basically, a big waste of time and money. So, we no longer respond to prescriptive RFQs/RFPs.

But, why is a prescriptive RFQ/RFP a bad thing for the client? Why is it a bad practice to be avoided at all costs?

It is a bad thing because it reduces the client’s options and severely narrows the search for the best solution. In our experience, a prescriptive RFQ/RFQ is simply the result of someone either asking for the product they first thought of someone who is so inflexible that he/she isn’t able to think outside the box and isn’t open to innovative solutions.

The end result of a prescriptive RFP/RFQ is always that the client ends up with a poor choice; with a third best or worse solution to the problem.

The message is very simple. If you want to find the best possible solution don’t tell the vendors what the solution is. Rather tell the vendors what the problem is and give them the opportunity to come up with the most innovative and cost-effective solution possible.  Give them the opportunity to be innovative and creative; don’t take away these so very important options.

Please do yourself, and your organization, a favour. If you want the best possible solution clearly explain what the problem is and then challenge the vendors to come up with their best shot. Prescriptive requirements always deny you the best solution.

Business Processes Management, BPM, BPO; just what does it entail?

by Frank 15. July 2012 06:00

Like me I am sure that you have been inundated with ads, articles, white papers and proposals for something called BPM or BPO, Business Process Management, Business Process Outsourcing and Business Process Optimisation.

Do you really understand what it all means?

BPM and BPO certainly aren’t new, there have been many companies offering innovative and often cutting-edge technology solutions for many years. The pioneering days were probably the early 1980’s. One early innovator I can recall (and admired) was Tower Technology because their office was just across from our old offices in Lane Cove.

In the early days BPM was all about imaging and workflow and forms. Vendors like Tower Technology used early version of workflow products like Staffware and a whole assortment of different imaging and forms products to solve customer processing problems. It involved a lot of inventing and a lot of creative genius to make all those disparate products work and actually do what the sales person promised. More often than not the final solution didn’t quite work as promised and it always seemed to cost a lot more than quoted.

Like all new technologies everyone had to go through a learning process and like most new technologies, for many years the promises were far ahead of what was actually delivered.

So, is it any different today? Is BPM a proven, reliable and feature-rich and mature technology?

The answer dear friends is yes and no; just as it was twenty-five or more years ago.

There is a wonderful Latin phrase ‘Caveat Emptor’ which means “Let the buyer beware”. Caveat Emptor applies just as much today as it did in the early days because despite the enormous technological progress we have all witnessed and experienced we are still pushing the envelope. We are still being asked to do things the current software and hardware can’t quite yet handle. The behind the scenes technicians are still trying to make the product do what the sales person promised in good faith (we hope) because he didn’t really understand his product set.

Caveat Emptor means it is up to the buyer to evaluate the offering and decide if it can do the job. Of course, if the vendor lies or makes blatant false claims then Caveat Emptor no longer applies and you can hit them with a lawsuit.  However, in reality it is rarely as black and white as that. The technology is complex and the proposals and explanations are full of proprietary terminology, ambiguities, acronyms and weaselly words.

Like most agreements in life you shouldn’t enter into a BPM contract unless you know exactly what you are getting into. This is especially true with BPM or BPO because you are talking about handing over part of your core business processes to someone else to ‘improve’. If you don’t understand what is being proposed then please hire someone who does; I guarantee it will be worth the investment. This is especially true if you are outsourcing customer or supplier facing processes like accounts payable and accounts receivable. Better to spend a little more up front than suffer cost overruns, failed processes and an inbox full of complaints.

My advice is to always begin with some form of a consultancy to ‘examine’ your processes and produce a report containing conclusions and recommendations. The vendor may (should) offer this as part of its sales process and it may be free or it may be chargeable.  Personally, I believe in the old adage that you get what you pay for so I would prefer to pay to have a qualified and experienced professional consultant do the study. The advantage of paying for the study is that you then ‘own’ the report and can then legally provide it to other vendors to obtain competitive quotes.

You should also have a pretty good idea of what the current processing is costing you in both direct and indirect costs (e.g., lost sales, dissatisfied customers, unhappy staff, etc.) before beginning the evaluation exercise. Otherwise, how are you going to be able to judge the added value of the vendor’s proposal?

In my experience the most common set of processes to be ‘outsourced’ are those to do with accounts payable processing. This is the automation of all processes beginning with your purchase order (and its line items), the delivery docket (proof of receipt), invoices (and line items) and statements. The automation should reconcile invoices to delivery dockets and purchase orders and should throw up any discrepancies such as items invoiced but not delivered, variations in price, etc. Vendors will usually propose what is commonly called an automatic matching engine; the software that reads all the documents and does its best to make sure you only pay for delivered goods that are exactly as ordered.

If the vendor’s proposal is to be attractive it must replace your manual processing with an automated model that is faster and more accurate. Ideally, it would also be more cost-effective but even if it is more costly than your manual direct cost estimate it should still solve most of your indirect cost problems like unhappy suppliers and late payment fees.

In essence, there is nothing magical about BPM and BPO; it is all about replacing inefficient manual processes with much more efficient automated ones using clever computer software. The magic, if that is the word to use, is about getting it right. You need to know what the current manual processing is costing you. You need to be absolutely sure that you fully understand the vendor’s proposal and you need to build in metrics so you can accurately evaluate the finished product and clearly determine if it is meeting its stated objectives.

Please don’t enter into negotiations thinking that if it doesn’t work you can just blame the vendor. That would be akin to cutting off your nose to spite your face. Remember Caveat Emptor; success or failure really depends upon how well you do your job as the customer.

Does the customer want to deal with a sales person?

by Frank 8. July 2012 06:00

We are in the enterprise content management business or more explicitly in the information management business and we provide a range of solutions including contract management, records management, document management, asset management, HR management, policy management, etc. We are a software company that designs and develops its own products. We also develop and provide all the services required to make our products work once installed at the customer’s site.

However, we aren’t in the ‘creating innovative software’ business even though that is what we do; we are really in the ‘selling our innovative software’ business because without sales there would be no business and no products and no services (and no employees).

We have been in business for nearly 30 years and have watched and participated as both technology and practices have evolved over that time. Some changes are easy to see. For example, we no longer product paper marketing collateral, we produce all of our marketing collateral in HTML or PDF form for delivery via our website and email. We also now market to the world via our website and the Internet, not just to our ‘local’ area.

Another major area of change has been the interface between the customer and the vendor. Many companies today no longer provide a human-face interface. Most big companies and government agencies no longer maintain a shopfront; they require you to deal with them via a website. Some don’t even allow a phone call or email; your only contact is via a web form.

Sometimes the website interface works but mostly it is a bit hit and miss and a very frustrating experience as the website fails or doesn’t offer the option you need. My pet hate is being forced to fill in a web form and then never hearing back from the vendor. Support is often non-existent or very expensive. From my viewpoint, a major failing of the modern paradigm is that I more often than not cannot get the information I need to evaluate a product from the website. This is when I try to find a way to ask them to please have a sales person contact me as I need to know more about their product or service.

I look forward to a sales person contacting me because I know what I want and I know what questions I need answers to. However, the sad truth is that I am rarely contacted by a sales person (and I refuse to speak to anyone from an Indian call centre because I have no wish to waste my time). However, experience with my customers and prospects tells me that not everyone is as enamoured with sales people as I am. In fact, many of the people I have contact with are very nervous of sales people, some are even afraid of them.

Unfortunately for me, we aren’t in a business where we can sell our products and services via a webpage and cart checkout. We need to understand the customer’s business needs before we can provide a solution so we need to employ high quality sales people who are business savvy and really understand business processes. It is not until I know enough to be able to restate the customer’s requirement in detail that I am in a position to make a sale. Conversely, the customer isn’t going to buy anything from me until he/she is absolutely sure I understand the problem and can articulate the solution.

So, in my industry I rely on a human interface and that usually means a sales person. But, do I really need a sales person and do my customers and prospective customers really want to speak to a sales person? Is there a more modern alternative? Please trust me when I say I have pondered this question many, many times.

Those in my business (selling information management solutions) will know how hard it is to find a good sales person and how hard it is to keep them. The good ones are less than ten-percent of the available pool and even after you hire them they are still besieged by offers from recruiters. Finding and retaining good sales people is in my opinion the biggest problem facing all the companies in our industry. They are also the most expensive of human resources and after paying a recruitment fee and a big salary you are then faced with the 80:20 rule; that is, 20% of the sales force produces 80% of your revenues.

Believe me, if I could find a way to meet my sales targets without expensive and difficult to manage sales people I would. However, as our solutions are all about adapting our technology to the customer’s often very complex business processes this is not a solution that can be sold via a website or automated questionnaire; it requires a great deal of skill and experience.

So for now dear customer, please deal with my sales person; he or she is your best chance of solving that vexing problem that is costing your organization money and productivity. All you really need to do is be very clear about what you want and very focussed on the questions you want answered. There is nothing to be afraid of because if you do your homework you will quickly be able to differentiate the good sales person from the bad sales person and then take the appropriate action. I never deal with a bad sales person and nor should you. I also really enjoy dealing with a professional sales person who knows his/her business and knows how to research and qualify my needs.

A good sales person uses my time wisely and saves me money. A bad sales person doesn’t get the chance to waste my time. This should be your approach too; be happy and willing to deal with a sales person but only if he/she is a professional and can add value to your business.

Sales people call this the value proposition. More explicitly; if the sales person is not able to articulate a value proposition to the customer that resonates with the customer then he/she shouldn’t be there. Look for the value proposition; if it isn’t apparent, close the meeting. Make each and every sales person understand, if they aren’t able to articulate a value proposition for your business then there is no point in continuing the conversation.

Dealing with a sales person isn’t difficult; it is all up to you to know what you want (the value proposition) and what questions to ask. Do your preparation and you will never fear a sales person again.

 

Why aren’t tablets the single solution yet?

by Frank 1. July 2012 06:00

We all know about the success of tablets both in the home and enterprise. It is one of those overnight success stories that took around ten years or more. The real breakthrough was the iPad and it is still the market leader and the trend setter; the one that all others try to emulate.

The fact that many tablets failed before the advent of the iPad and that many more have failed since is testimony to the uniqueness of the iPad, to its creators getting it ‘just right’ and to Apple being the premier marketing organization of our time. The fact that the iPad outsells all of its competitors despite having fewer features is due to the understated brilliance of its design and Apple’s overachieving marketing department.

Despite their best efforts, huge budgets and amazing technology, both HP and Samsung have failed to topple the iPad. Now we have Microsoft with its vapourware Surface about to attempt the same task; good luck Microsoft but for now I am placing my bets on Apple to win this contest. Then again, maybe Google’s coming Nexus 7 tablet will be the deal-breaker?

I own an iPad 2 and a Samsung Galaxy Tab and despite the Samsung having more capabilities I would choose the iPad every time and it is the one I carry around with me despite the missing USB port and sandboxed file system. It wins because it is just ‘right’; it is super easy to configure and use and just does what it is supposed to do without irritating bugs, idiosyncrasies or pain. This is due to the maturity and robustness of iOS. The Samsung on the other hand suffers because of the immaturity and instability of the Android operating system; I feel sorry for Samsung because they have done a good job with the hardware only to be let down by the software. Google, are you listening?

However, the iPad has not replaced my smart-phone, desktop computer or laptop and it isn’t likely to until it matures and grows a lot past both the iPad 2 and the stupidly named New iPad (I guess even Apple can’t get it right every time). The reasons are pretty self-evident:

·         It can’t run all the applications I need

·         Its screen is too small for some jobs

·         It is too big to replace my phone and doesn’t work as a phone

·         It has limited connectivity

·         The sandboxed file system is next to useless when I need to transfer data between applications. In fact, you may as well say it doesn’t have a file system.

·         It can’t be networked (connecting via Wi-Fi is not the same as networking; for enterprise use it needs to connect to Active Directory)

So even though the iPad is the ‘best’ it is still light years away from being the single device I could use in my business. This means it is an ‘additional’ device, not a replacement. I still need my smartphone and my desktop and my laptop and this is just too silly for words because all of these devices can receive and send emails, all of these devices can receive and send messages and all of these devices allow me to type and create and read documents, etc., etc. There is an enormous overlap of functionality, a duplication of functionality which is more than silly; it is stupid; why am I receiving the same email on four devices?

You may ask then why do I have four devices? The simple answer is that each one of them is more appropriate in a given situation. For example, at my desk there is nothing better than the desktop, in the airport just before my flight the smart-phone is best, in my hotel room the night before the meeting the laptop is perfect and while having coffee just before a meeting the iPad is the ideal device. However, none of them are appropriate for all the things I do and all the places I go. This is the major dilemma of the modern office worker.

I do not want to work with four devices, I do not want to carry three devices (phone, laptop and iPad) on business trips and I think it is just plain dumb to have to send and receive the same email on four different devices. We need a single solution and everyone in the industry tells me it will be a tablet but I have yet to see a tablet that fits the bill or even comes close.

I want a screen big enough to view and compose important documents or presentations. I want a real keyboard. I want connectivity, I want security. I want to be able to run all the applications I need to run my business. I also want lightness and small size and a phone. I am not Robinson Crusoe; every business person I speak to wants the same capabilities and until tablets can come close to satisfying my needs they will never be the single device business people need.

To all the tablet makers out there, Apple, Samsung, HP, Lenovo, Google, and the like; please, please listen to your customers and produce a new generation device that will simplify our lives and reduce our load. Please give me a single device that does everything.

Where have all the (good) applicants gone?

by Frank 24. June 2012 06:00

I am told again and again by the popular press and unpopular politicians (is there any other kind?) that we in Australia have a skills shortage. I agree but with a strong proviso; we have a skills shortage but we don’t have an applicant shortage.

We have been advertising for a support specialist (we actually hired one), software sales people and experienced .NET programmers. We are trying to grow and expand and the lack of good quality staff is the major impediment.

I have placed the ads on SEEK, on LinkedIn and am also using the services of several recruiting firms so we at least have a wide coverage.

The initial problem is that the majority of candidates either don’t read the ad or don’t understand the ad or just plain ignore the requirements in the ad. Please note that we are talking about very clear and unambiguous requirements like:

  • Please note that applications without a personalised cover letter articulating why you have the right attributes to be successful in this role will not be considered.
  • Previous applicants need not apply and all applicants must be Australian citizens or legal residents.

We also list skill or experience prerequisites which most applicants also either misread, don’t understand or just plain ignore. Again, we list them very clearly as follows:

  • You will have 3+ years’ experience programming in .NET (preferably VB)
  • You will have 3+ years’ experience working with SQL Server (2005/2008)
  • Experience with the most of the following: .NET 3.5, ASP, AJAX, LINQ, Threading, Web Services, JavaScript, IIS

Of course, as you may guess, the next biggest problem is that the claims in the resume/curriculum vitae simply do not match reality. We for example now test all programing applicants and less than ten-percent of the people we interview come even close to passing a simple programming test. For example, applicants who claim to be certified and experts in topics like SQL are unable to answer even the most elementary questions about SQL.

The funniest (strangest?) thing is that invariably, when we ask them after the test why they rated themselves as a 9 out of 10 in SQL but don’t seem to know anything about SQL, they still rate themselves as a 9 out of ten. It is at that point that you realise there is no point in continuing the interview.

We have now changed our approach and in order not to waste time we conduct a simple phone interview with applicants before deciding to bring them in. As you would guess, most never get past the simple phone interview.

In a nutshell, the ‘norm’ appears to be that applicants ignore the requirements in the ad and also lie about their experience and skills in their resumes. Sometimes the lies are so obvious it is funny. For example, we always check applicants in social networking sites like LinkedIn. The differences between the public profile on LinkedIn and the resume we receive are often amazing; different companies, different titles, different dates of employment. It reminds me of that old question, “Are you lying now or were you lying then?” As soon as we see big differences between the LinkedIn profile and the resume we lose interest.

Recruiters are also in the main, simple hopeless. They want a huge fee for placing an ad on SEEK and sending you a resume. Most don’t interview candidates or screen them in any way or even check references and none take any responsibility. Most beg for an appointment so they can really understand your requirements and then totally ignore them after taking up an hour or two of your valuable time.

However, even after the ‘information-gathering’ appointment and us supplying the recruiter with detailed written requirements the first few resumes we receive are usually nothing like what we asked for. Invariably, when I summon up enough patience to call them as ask why they wasted my time sending me resumes that are nothing like our requirements the answer is usually, “Oh, I thought you might be interested in this one.” Luckily I am not in the habit of gnashing my teeth or I would have none left.

Let me translate that response, “I am a recruiter on a low base salary and high commission and I can’t pay the mortgage on my girlfriend’s flat unless you take one of my candidates so I am going to send you whatever I have in the hope I can earn some commission.”

Then there is the question of literacy and professionalism or the lack thereof. To be fair, a lot of our programming candidates (most actually) are new to this country and English isn’t their first language so we expect to see some unusual phrasing and sentence construction in the resume. Most programming candidates however, despite language difficulties, do a pretty good job in the resume. It is only when we do a phone interview that we discover the candidate’s real grasp of English and unfortunately, for most new arrivals, I can’t employ them in my development environment if they can’t communicate technical matters and nuances at an expert level. It isn’t my job to teach them English.

The real surprise, or shock, is the number of ‘sales professionals’ who can’t spell or construct a sentence or even format a document despite English being their first language. I need these people to be able to construct well-written, cohesive selling proposals for my clients and if the resume is an indicator of their abilities then they fail abysmally.

More importantly, you have to ask if this is the effort they put into an extremely important document selling themselves what hope do you have of getting a well-written and totally professional proposal for your customers? We simply reject any sales candidate with a poorly written and formatted resume.

It is strange that most resumes from programming candidates who are also recent arrivals to our country are generally much better written that the resumes of so-called experienced sales professionals who were schooled here. There is obviously something seriously amiss with our education system and the standards of the companies they worked for previously.

The sad bottom line is that out of one hundred applicants we will only want to interview ten and out of those ten only one will prove to be suitable. I would like to say that this is a one-percent success rate but it isn’t because the one good candidate always gets several offers and the chance of actually hiring them is no better than one in two. This give me a success rate of at best, one in two-hundred.

My theory is that there is a major mismatch between available candidates and the available positions with a lot of poorly qualified people in the market and very few highly qualified people in the market. So we definitely have an ‘available’ skills shortage. It is an awful thing to say but I can only see this situation getting worse in the next few years as our economy slows down because the few good people are going to stay where they are and wait out the bad times.

Where are those cyborgs I see in movies like Prometheus; how much do I have to pay and how long do we have to wait?

 

Why is the Web-Client a much better solution for applications?

by Frank 17. June 2012 06:00

When we see terms like Web-Client or Thin-Client it means an application that runs in a browser like IE, Firefox or Chrome. The alternative is a Fat-Client usually meaning an application that runs within Windows (XP, Vista, Windows 7) on your desktop or notebook.

Neither the Web-Client nor the Fat-Client are new concepts having been around for many years but both have changed and improved over time as they have employed new technologies. Most Fat-Client applications today for instance are based on the 2008 or 2010 Microsoft .NET platform and require the .NET Framework to be installed on the workstation or notebook. Most Web-Client applications today utilize advanced multi-tier tools like those from Ajax plus more advanced toolsets from development systems like Visual Studio 2010 and provide a far better user interface and experience than their ancestors did.

In a nutshell, in the old days say fifteen years ago, Web-Clients were clunky, two-tier and had terrible user interfaces, nowhere near as good as their Fat-Client counterparts. Today, using the advanced development tools available, it is possible to build a Web-Client that looks and works little different from a Fat-Client. Much better development tools have made it much easier for programmers to build nicer looking, more functional and easier to use Web-Client user interfaces for applications.

It still isn’t all roses because not all browsers are equal and different browsers (e.g., IE versus Safari) and different versions of browsers (e.g., IE 6, 7, 8 and 9) force the programmer to have to write extra code to handle the differences. The advent of HTML5 will soon introduce another layer of differences and difficulty as vendors deploy different or non-standard versions of the HTML5 standard. However, this has been the case for as long as I can remember (there have always been differences in the HTML deployed by different vendors) and us programmers are used to it by now.

It used to be that because of the limited development tools available to code Web-Client interfaces that the typical Web-Client had far less functionality than its Fat-Client equivalent. Whereas it is still easier to implement complex functionality in a .NET Fat-Client than a Web-Client, it is possible to provide equivalent functionality in a Web-Client; it just needs smarter programmers, more work and a few extra tools.

So if your application vendor offers you the choice of a Fat or Web user interface, which should you choose and why?

You first need to ask a couple of very important questions:

·         Does the Web-Client have equivalent functionality to the Fat-Client? and

·         Is the Web-Client operating system and browser independent?

Let’s address the second question first because it is the most important. You can for example, write a Web-Client user interface that it not operating system independent and that in fact is ‘locked’ into a particular operating system like Windows and a particular browser like IE8. Most Silverlight Web-Client applications for instance require that the .NET Framework be installed on the local workstation or notebook. As the .NET Framework only works on Microsoft Windows systems it means you can’t run your Web-Client on other systems such as Linux, Mac OS, iOS or Android.

It also means that your IT department has to install and maintain software on each and every workstation or notebook that needs to run the application. This is the big problem because the cost of installing and maintaining software on each and every desktop and notebook is enormous.

Ideally, the Web-Client will be operating system independent and will support most of the latest versions of the most popular browsers. Expecting the Web-Client to support old versions of browsers is an unreasonable expectation.

If the Web-Client is operating system independent and has the same functionality as the Fat-Client then your decision is a foregone conclusion; go with the Web-Client and save on the installation and ongoing maintenance costs that would apply to the Fat-Client but not to the Web-Client.

If the Web-Client has a subset of the functionality of the Fat-Client you then need to compare the functionality offered to the needs of different classes of your users. It may not suit your systems administrator but will it suit inquiry users who just need to be able to browse, search, view and print? Will it also suit the middle-class of users who need to be able to add, modify and delete records but not perform administrative tasks like designing reports and building workflow templates?

It is important to have as many of your users as possible using the Web-Client because not only will this approach reduce your IT costs it will provide extra benefits for users who travel and operate from remote and poorly serviced locations not to mention those who work from home. After all, all that is needed is a computer (or tablet or smart-phone) and a secure Internet connection.  

Obviously, as a Web-Client runs from a Web Server your IT people need to ensure that it is secure and for example, operates as a secure and encrypted HTTPS website rather than as an insecure HTTP website. All traffic from public sites needs to be encrypted both ways as a minimum security requirement.

The other major benefit of the Web-Client is that it protects you from differences in operating systems, e.g., Windows XP versus Windows 7 or even Windows 8. A Web-Client runs in the browser, not in Windows so it is much less affected by fundamental changes in an operating system than a Fat-Client application which has to be re-compiled and re-certified against every change. Importantly, you are not locked in to a particular operating system or version of an operating system.

I expect most application vendors to be moving their customers to a Web-Client end user platform; we certainly will be and are investing large amounts of dollars in our RecFind 6 Web-Client interface. There are enormous cost and convenience benefits to our customers in moving from our Fat-Client to our Web-Client user interface and we will be doing everything in our power to encourage this move.

 

Integration, what does it really entail?

by Frank 10. June 2012 06:00

Over the last 28 years of running this business I have had hundreds of conversations with customers and partners about integration. In most cases when I have tried to obtain more details about exactly what they wanted to integrate to and how I have drawn a blank. It is as if the word ‘integration’ has some magical connotation that everyone is supposed to instantly understand. Being a very logical and technical person, I guess I fail the test because to me it is just a general term that covers a multitude of possibilities.

I have also designed and/or programmed many integrations in my life and I can honestly say that no two have ever been the same. So, assuming that you have a requirement for two or more of the application software products you use to ‘integrate’ how should you go about defining what is required so it is as clear and as unambiguous as possible to your partners, the people you will ask to do the work?

Integration is usually about sharing information and importantly, not duplicating effort (i.e., having to enter data twice) or duplicating information. Having to enter the same information twice into two different systems is just plain dumb and bad design. Maintaining duplicate copies of information is even dumber and dangerous because sooner or later they will get out of step and you will suffer from what we call a loss of data integrity. This is usually why we need integration, to share information and to avoid duplicate effort and duplicate information.

For our purpose let’s assume that we have two application systems, A and B, that we need to be ‘integrated’; both use a SQL database to store data. Applications A and B are produced by different vendors that haven’t worked together before. The first fact to face is that in the normal course of events each vendor is going to want the other vendor to do all the work and each vendor is going to want the other vendor to utilize its proprietary integration methodology (e.g., Application Program Interface (API) or Software Development Kit (SDK)). This is your first big challenge; you need to get the vendors to agree to work together because no matter how this turns out both are going to have to do work and contribute; you can’t complete an integration using just one vendor. That is, the most important thing you have to do is to manage the vendors involved. You can’t just leave it up to them; you need to manage the process from beginning to end.

The second most important thing you have to do is to actually define and document the integration processes as clearly as possible. Here is a checklist to guide you:

1.    Will application A need to access (i.e., read) data held by application B?

2.    Will application B need to access data held by application A?

3.    How often and at what times is access to data required? All the time, once a day, once a week, only when something changes, only when there is new data, every time a new record is added to either application A or B, etc. What are the rules?

4.    How is the data identified? That is, how does application A know what data it needs to access in the application B database? Is it by date or special code or some unique identifier? What are the rules that determine the data to be accessed?

5.    Will application A need to transfer data to application B (i.e. write data to the B database)?

6.    Will application B need to transfer data to application A?

7.    How often and at what times is a transfer of data required? All the time, once a day, one a week, only when something changes, only when there is new data, every time a new record is added to either application A or B, etc. What are the rules?

8.    How is the data identified? That is, how does application A know what data it needs to transfer to the application B database? Is it by date or special code or some unique identifier? What are the rules that determine the data to be transferred?

9.    Does application A have an API or SDK?

10.What is the degree of difficulty (expertise required, time and cost) of programming to this API or SDK? Rate it on a scale of 1 to 10, 10 being the most difficult and most expensive and most time consuming.

11.Does application B have an API or SDK?

12.What is the degree of difficulty (expertise required, time and cost) of programming to this API or SDK? Rate it on a scale of 1 to 10, 10 being the most difficult and most expensive and most time consuming.

13.Is the vendor of application A happy to assign a suitable qualified technical person (not a sales person or pre-sales person) to be the interface?

14.Is the vendor of application B happy to assign a suitable qualified technical person (not a sales person or pre-sales person) to be the interface?

15.What is your timescale? When does it have to be completed? What is the ‘driver’ event?

16.What is your budget? Basically vendors work in a commercial environment and if they do work then they expect to get paid. As a rule, the size of the budget will depend directly upon your management skills and the quality of your integration specification.

Please keep it in mind that there are always multiple ways to integrate; there is never just a single solution. The best way is always the simplest way and this is usually also the lowest cost and quickest way as well as being the lowest cost to maintain. Think about the future, the most complex solution is always the most difficult and most expensive ongoing maintenance solution. Think KISS; minimize your pain and expense.

As a guideline, the vendor with the most work to do is usually the best one to be the ‘lead’ in the integration (remember, both have to be involved or it won’t work). So, if for example vendor A needs to read data from Vendor B’s database and then massage it and utilize it within application A then vendor A is the natural lead. All vendor B has to do is expose its API and provide the required technical assistance to vendor A so vendor A can successfully program to the API.

However, in the end it will usually be the vendor that is the most cooperative and most helpful that you will choose. If you choose the vendor you most trust and work best with to be the lead then you will maximize your chances of completing a successful integration on time and on budget.

 

Your help desk works, or does it?

by Frank 3. June 2012 06:00

Almost every organization, commercial or government, needs a help desk. Help desks support either internal or external ‘customers’. Generally speaking the job of a help desk is to support users who have problems or questions about a product or service.

Help desks may run as either a profit centre or as a cost centre. Normally, help desks supporting internal customers run as cost centres (though maybe with an internal accounting function that attempts to allocate costs to all the departments that utilize the service) and help desks that support external customers run as a profit centre, charging for their services via an annual service fee or incident fee.

The only true measure of the worth of a help desk is the level of customer satisfaction and this is very difficult to measure other than in an anecdotal way. This is because of human nature; customers who are happy with the service rarely take the time to write to the help desk manager and tell him. The same is true of customers who are unhappy with the service; most just make a decision not to use that product or service again. A small number of very disgruntled or even litigious or nuisance customers will complain repeatedly in the most vociferous and rudest manner but will largely be ignored as repeat offenders or the usual suspects.

Trying to get a reading across the customer base by using a survey rarely works either as most won’t respond  and the ones that do respond are usually from the two extremes, the really, really happy customers and the really, really dissatisfied customers. Plus, we all know that a survey is like a poll, if you design the questions in a certain way you can always get the result you first thought of.

Because it is so difficult to obtain enough customer input to be able to rate the help desk we usually fall back on internal metrics. Such things as how many calls did we receive last week? What percentage was closed within 1 day, 2 days, 3 days, etc.? How many are still outstanding after 7 days? How many had to be escalated?

The problem with internal metrics, like police reports on crime statistics, is that they can be manipulated to produce the result you first thought of. Remember that old saying about statistics, "Lies, damned lies, and statistics." A smart and politically savvy help desk manager will always find a way to guild the lily and dress up the stats so he looks good.

So, how do you know if your help desk is working and servicing your customers to the highest standard? There is only one sure way I know of and that is to ring the help desk yourself (incognito I hope, calling up and saying this is the CEO won’t really give you a fair reading about how ordinary customers are treated), or organize a team to call the help desk with a list of known issues and test the responses.

This sounds like it should be a business opportunity; a kind of reverse outsourced help desk, an organization that specializes in testing help desk services. All you have to do is provide them with scripts and a way to measure the effectiveness of the responses. However, I don’t know of any organization that provides this service just as I have never met a CEO lately who seems to know or care what is happening with his help desk service and this is the real problem.

You can always tell the company with the disinterested CEO because there is no way to contact him or her on the website. Companies that aren’t interested in supporting customers always make it almost impossible for a customer to provide feedback. Unfortunately, this ‘we are hiding from you approach’ is becoming the norm as companies remove all contact information from their websites and force customers to endure long waits and rubbish ‘service’ from outsourced support centres.

The executives don’t receive negative feedback because they make it so difficult for customers to reach them. Personally, I think this is a short term and eventually damaging practice as customers tend to have long memories and frustrated, dissatisfied customers will make it their business to tell everyone but the company’s management team (because they aren’t able to contact them) about the rubbish product and the shoddy way they were treated.

Before you ask, let me explain that we do have a support centre but it is not outsourced and we make it as easy as possible for customers to contact us by web form, email, mobile device or toll free number. Please see the links below:

http://www.knowledgeonecorp.com/support/contactinghelpdesk.htm

http://www.knowledgeonecorp.com/contactus/emailus.htm

http://www.knowledgeonecorp.com/contactus/Contact_By_Mobile_App.htm

http://www.knowledgeonecorp.com/support/freeemailsupport.htm

support@knowledgeonecorp.com

Just so you know that we practice what we preach.

Paradoxically, I believe the reason that I get so few complaints (apart from the high standard of our support services) is that I make it so easy for customers to contact me or any other executive in my company.

We also use our own product RecFind 6 as our help desk software so we are able to build in all the alerts, escalations and reporting we need to manage each and every support call to the best of our ability. And finally, my office is just 20 metres or so from the support centre so I make it my business to be in there talking to the support staff at least 4 or 5 times a day.

I am a CEO who is vitally interested in his customers and the quality of support they are receiving and not just for altruistic reasons but for sound business reasons.  Happy customers stay with us and invest in our products and services year after year. It is quite simple really; I invest in my customers so they will invest in my company. It works for us and I wonder why other CEO’s don’t understand this very simple message.

The relationship between a vendor and a customer should be a mutually beneficial partnership; it should not be an destructive, adversarial relationship. In my opinion CEO’s who do not allow their customers to contact them and deliver either a complaint or a compliment are fools and bad business people with a strictly short term view. It is a formula for more short term profit but less long term customers. We opt to spend more money and time on support so we can foster better long term relationships. I think in the ‘old days’ this used to be called service.

What is really involved in converting to a new system?

by Frank 27. May 2012 06:00

Your customer’s old system is now way past its use by date and they have purchased a new application system to replace it. Now all you have to do is convert all the data from the old system to the new system, how hard can that be?

The answer is it that can be very, very hard to get right and it can take months or years if the IT staff or the contractors don’t know what they are doing. In fact, the worst case is that no one can actually figure out how to do the data conversion so you end up two years later still running the old, unsupported and now about to fail system. The really bad news is that this isn’t just the worst case scenario, it is the most common scenario and I have seen it happen time and time again.

People who are good at conversions are good because they have done it successfully many times before. So, don’t hire a contractor based on potential and a good sales spiel, hire a contractor based on record, on experience and on a good many previous references. The time to learn how to do a conversion isn’t on your project.

I will give you guidelines on how to handle a data conversion but as every conversion is different, you are going to have to adapt my guidelines to your project and you should always expect the unexpected. The good news is that if you have a calm, logical and experienced head then any problem is solvable. We have handled hundreds of conversions from every type of system imaginable to our RecFind product and we have never failed even though we have run into every kind of speed bump imaginable. As they say, “expect the best, plan for the worst, and prepare to be surprised.”

1.    Begin by reviewing the application to be converted by looking at the ‘screens’ with someone who uses the system and understands it. Ask the user what fields/data they want to convert. Take screenshots for your documentation. Remember that a field on the screen may or may not be a field in the database; the value may be calculated or generated automatically. Also remember that even though a screen may be called say “File Folder” that all the fields you can see may not in fact be part of the file folder table, they may be ‘linked’ fields in other tables in the database.

2.    You need to document and understand the data model, that is, all the tables and fields and relationships you will need to convert. See if someone has a representation of the data model but, never assume it is up to date. In fact, always assume it is not up to date. You need to work with an IT specialist (e.g., the database administrator) and utilize standard database tools like SQL Server Management Studio to validate the data model of the old system.

3.    Once you think you understand the data model and data to be converted you need to document your thoughts in a conversion report and ask the customer to review and approve it. You won’t get it right first time and expect this to be an iterative process. Remember that the customer will be in ‘discovery’ mode also.

4.    Once you have acceptance of the data to be converted you need to document the data mapping. That is, show where the data will go in the new application. It would be extremely rare that you would be able to duplicate the data model from the old application; it will usually be a case of adapting the data from the old system to the different data model of the new application. Produce a data mapping report and submit it to the customer for sign-off. Again, don’t expect to get this right the first time; it is also an iterative process because both you and the customer are in discovery mode.

5.    Expect that about 20% or more of the data in the old system will be ‘dirty’; that is, bad or duplicate and redundant data. You need to make a decision about the best time to clean up and de-dupe the data. Sometimes it is in the old application before you convert but often it is in the new application after you have converted because the new application has more and better functionality for this purpose.   Whichever method you choose, you must clean up the data before going live in production.

6.    Expect to run multiple trial conversions. The customer may have approved a specification but reading it and seeing the data exposed in the new application are two very different experiences. A picture is worth a thousand words and no one is smart enough to know exactly how they want their data converted until they actually see what it looks like and works like in the new application. Be smart and bring in more users to view and comment on the new application; more heads are better than one and new users will always find ways to improve the conversion. Don’t be afraid of user opinion, actively encourage and solicit it.

7.    Once the data mapping is approved you need to schedule end-user training (as close as possible to the cutover to the new system) and the final conversion prior to cutover.

Of course for the above process to work you also need the tools required to extract data from the old system and import it into the new system. If you don’t have standard tools you will have to write a one-off conversion program. The time to write this is after the data mapping is approved and before the first trial conversion. To make our life easy we designed and build a standard tool we call Xchange and it can connect to any data source and then map and write data to our RecFind 6 system. However, this is not an easy program to design and write and you are unlikely to be able to afford to do this unless you are in the conversion business like we are. You are therefore most likely going to have to design and write a one-off conversion program.

One alternative tool you should not ignore is Microsoft’s Excel. If the old system can export data in CSV format and the new system can import data in CSV format then Excel is the ideal tool for cleaning up, re-sequencing and preparing the data for import.

And finally, please do not forget to sanity check your conversion. You need to document exactly how many records of each type you exported so you can ensure that exactly the same number of records exist in the new system. I have seen far too many examples of a badly managed conversion resulting in thousands or even millions of records going ‘missing’ during the conversion process. You must have a detailed record count going out and a detailed record count going in. The last thing you want is a phone call from the customer a month or two later saying, “it looks like we are missing some records.”

Don’t expect the conversion to be easy and do expect it to be an iterative process. Always involve end-users and always sanity check the results.  Take extra care and you will be successful.

Month List