I am willing to bet that you are still not managing your emails effectively

by Frank 25. November 2012 06:00

According to various industry surveys, 65% to 75% of companies still have no systems in place to manage email records. Based on my own observations and dialog with Knowledgeone Corporation’s customers and prospects, I would say the percentage is far higher; say 85% or more. My guess is that the industry surveys inadvertently included a number of email ‘cleaning’ systems as email management systems; thereby skewing the figures.

 

Given that there is now a variety of proven email management systems (like Knowledgeone Corporation’s GEM) available for most email servers (e.g., Exchange, GroupWise and Notes) and given the enormous danger of unmanaged email it is, on the surface, difficult to explain the apparent reluctance of organizations to implement email management policies and systems.

 

My own experience leads me to believe that the following are the major reasons organizations do not take this critical step:

1. Lack of ownership and leadership

Email management transects all of the traditional vertical organizational boundaries. There may well be an IT person in charge of the email servers but there is rarely a senior management person in charge of email organization-wide. That is, no one person actually ‘owns’ the problem and no one person has the authority to implement an organization-wide solution.

2. Lack of an understanding of the problem and of the solution

Most of the people who are senior enough in an organization to be aware of this problem do not comprehend the complexities of the problem. They have dialogs with IT people who explain the issues in technical terms, not in business or risk-management terms. Email management should come under an organization’s risk management regime because that is where a great deal of risk lies.

3. Lack of desire to solve the problem plus active opposition to a solution

There are a large number of IT people and others in every organization who simply do not want their emails managed, analysed, scrutinized, indexed and saved. This fact is never going to change and must always be addressed at a senior level by the person responsible for risk management policies and practice. Uncooperative and/or recalcitrant employees should not be allowed to put an organization at risk no matter what their position in the management hierarchy.

4. Confusion over what is involved in complying with a plethora of laws and regulations

One hundred percent of what well-meaning bureaucrats and politicians have done to ‘solve’ what they see as email privacy issues has been badly thought out, badly drafted and counterproductive; simply ill-informed, knee-jerk reactions. As you can see, I am no fan of politicians and bureaucrats who pass knee-jerk laws without understanding or caring about the full implications.

 

As far as I am concerned the privacy issue is secondary to the fact that every employer has to right to determine how its resources are used. Every employer has the right to protect itself. Every employer has the right to tell its employees if private emails are allowed or not. Every employer has the right to tell its employees what is acceptable and what is not acceptable in an email.

 

Solving the so called privacy policy is dead easy; herewith is the McKenna solution.

 

Tell employees that:

1. Private emails are not allowed and all emails will be scrutinized for inappropriate content; or

2. Private emails are allowed (in moderation) but that all emails, including private emails, will be scrutinized for inappropriate content; or

3. Private emails are allowed (in moderation) but that they MUST be identified by the keyword “Private” (or a word or phrase of your choice) in the subject line. All emails without the keyword “Private” in the subject line will be scrutinized for inappropriate content.

5. Confusing and misleading claims by companies marketing email management systems

It is a complex problem (have you ever tried to set up a multi-server email system in a large organization?) often poorly understood and poorly explained by the sales person. Add to this the fact that the sales person is usually speaking to the IT person (who lives in a different universe) who then has to ‘translate’ what he thinks the sales person said to senior management. Too often, the harried sales person, under intense pressure from the IT interrogator, will simply say “Yes” without really understanding the question or its implications.

 

My best advice to senior management is that if they don’t fully understand, keep asking questions until they do or, seek assistance from an independent authority. It is just plain dumb and dangerous to sign something off you don’t really understand.

6. Multiple and conflicting objectives

Is your objective to simply be aware of everything that is in your email store or is it to also meet a plethora of complex and competing regulations and certification standards?

 

Have you inadvertently set the goal post too high? Have you made the problem many times more complex than it should be? Has it become a “Wish List” instead of a requirement? Is the selection of a suitable product always held up by someone demanding that it has to also do something else? Has your horse now morphed into a camel?

 

My best advice? Why don’t you try ‘Getting wet slowly’ and review your needs again when the basic but critical email management problem is solved?

 

In the end it is about ownership, understanding and will. If just one senior person with the necessary authority understands the problem and commits to a solution then it will happen. The solutions are out there; they are just waiting for a committed purchaser with a clear and simple view of what needs to be achieved.

 

You must be aware of what is in your email store and you must be alerted to infringements before they grow into expensive problems. You can’t do this without an email management system in place.

 

Can you save money with document imaging?

by Frank 4. November 2012 06:00

I run a software company called Knowledgeone Corporation that produces an enterprise content management solution called RecFind 6 that includes extensive document imaging capabilities. We have thousands of customers around the world and as far as I can see most use RecFind 6 for document imaging of one kind or another.

This certainly wasn’t the case twenty years ago when document imaging tools were difficult to use and were expensive stand-alone ‘specialised’ products. Today however, almost every document management or records management product includes document imaging capabilities as a normal part of the expected functionality. That is, document imaging has gone from being an expensive specialised product to just a commodity, an expected feature in almost any information management product.

This means most customers have a readily available, easy-to-use and cost-effective document imaging tool at their fingertips. That being the case there should be no excuse for not utilizing it to save both time and money. However, I guarantee that I could visit any of my customers and quickly find unrealised opportunities for them to increase productivity and save money by using the document imaging capabilities of my product RecFind 6. They don’t even have to spend any money with me because the document imaging functions of RecFind 6 are integrated as ‘standard’ functionality and there is no additional charge for using them.

So, why aren’t my customers and every other vendor’s customers making best use of the document imaging capabilities of their already purchased software?

In my experience there are many reasons but the main ones are:

Lack of knowledge

To the uninitiated document imaging may look simple but there is far more to it than first appears and unless your staff have hands-on experience there is unlikely to be an ‘expert’ in your organization. For this reason I wrote a couple of Blogs earlier this year for the benefit of my customers; Estimating the cost of your next imaging job and The importance of document imaging. This was my attempt to add to the knowledge base about document imaging.

Lack of ownership

The need for document imaging transects the whole enterprise but there is rarely any one person or department charged with ‘owning’ this need and with applying best-practice document imaging policies and procedures to ensure that the organization obtains maximum benefits across all departments and divisions. It tends to be left to the odd innovative employee to come up with solutions just for his or her area.

Lack of consultancy skills

We often say that before we can propose a solution we need to know what the problem is. The way to discover the true nature of a problem is to deploy an experienced consultant to review and analyse the supposed problem and then present an analysis, conclusions and recommendations that should always include a cost-benefit analysis. In our experience very few organizations have staff with this kind of expertise.

Negative impact of the Global Financial Crisis that began in 2008

All over the world since 2008 our customers have been cutting staff and cutting costs and eliminating or postponing non-critical projects. Some of this cost cutting has been self-defeating and has produced negative results and reduced productivity. One common example is the cancelling or postponing of document imaging projects that could have significantly improved efficiency, productivity and competitiveness as well as reducing processing costs.  This is especially true if document imaging is combined with workflow to better automate business processes.  I also wrote a Blog back in July 2012 for the benefit our customers to better explain just what business process management is all about called Business Process Management, just what does it entail?

In answer to the original question I posed, yes you can save money utilizing simple document imaging functionality especially if you combine the results with new workflow processes to do things faster, more accurately and smarter. It is really a no-brainer and it should be the easiest cost justification you have ever written.

We have already seen how most information management solutions like RecFind 6 have embedded document imaging capabilities so most of you should have existing and paid-for document imaging functionality you can leverage off.

All you really need to do to save your organization money and improve your work processes is look for and then analyse any one of many document imaging opportunities within your organization.

A clue, wherever there is paper there is a document imaging opportunity.

Are you also confused by the term Enterprise Content Management?

by Frank 16. September 2012 06:00

I may be wrong but I think it was AIIM that first coined the phrase Enterprise Content Management to describe both our industry and our application solutions.

Whereas the term isn’t as nebulous as Knowledge Management it is nevertheless about as useful when trying to understand what organizations in this space actually do. At its simplest level it is a collective term for a number of related business applications like records management, document management, imaging, workflow, business process management, email management and archiving, digital asset management, web site content management, etc.

To simple people like me the more appropriate term or label would be Information Management but as I have already covered this in a previous Blog I won’t beleaguer the point in this one.

When trying to define what enterprise content management actually means or stands for we can discard the words ‘enterprise’ and ‘management’ as superfluous to our needs and just concentrate on the key word ‘content’. That is, we are talking about systems that in some way create and manage content.

So, what exactly is meant by the term ‘content’?

In the early days of content management discussions we classified content into two broad categories, structured and unstructured. Basically, structured content had named sections or labels and unstructured content did not. Generalising even further we can say that an email is an example of structured content because it has commonly named, standardised and accessible sections or labels like ‘Sender’, ‘Recipient’, ‘Subject’ etc., that we can interrogate and rely on to carry a particular class or type of information. The same general approach would regard a Word document as unstructured because the content of a Word document does not have commonly named and standardised sections or labels. Basically a Word document is an irregular collection of characters that you have to parse and examine to determine content.

Like Newtonian physics, the above generalisations do not apply to everything and can be argued until the cows come home. In truth, every document has an accessible structure of some kind. For example, a Word document has an author, a size, a date written, etc. It is just that it is far easier to find out who the recipient of an email was than the recipient of a Word document. This is because there is a common and standard ‘Tag’ that tells us who the recipient is of an email and there is no such common and standard tag for a Word document.

In our business we call ‘information about information’ (e.g., the recipient and date fields on an email) Metadata. If an object has recognizable Metadata then it is far easier to process than an object without recognizable Metadata. We may then say that adding Metadata to an object is the same as adding structure.

Adding structure is what we do when we create a Word document using a template or when we add tags to a Word document. We are normalizing the standard information we require in our business processes so the objects we deal with have the structure we require to easily and accurately identify and process them.

This is of course one of the long-standing problems in our industry, we spend far too much time and money trying to parse and interpret unstructured objects when we should be going back to the coal face and adding structure when the object is first created. This is of course relatively easy to do if we are creating the objects (e.g., a Word document) but not easy to achieve if we are receiving documents from foreign sources like our customers, our suppliers or the government. Unless you are the eight-hundred pound gorilla (like Walmart) it is very difficult to force your partners to add the structure you require to make processing as fast and as easy and as accurate as possible.

There have been attempts in the past to come up with common ‘standards’ that would have regulated document structure but none have been successful. The last one was when XML was the bright new kid on the block and the XML industry rushed headlong into defining XML standards for every conceivable industry to facilitate common structures and to make data transfer between different organizations as easy and as standard as possible. The various XML standardisation projects sucked up millions or even billions of dollars but did not produce the desired results; we are still spending billions of dollars each year parsing unstructured documents trying to determine content.

So, back to the original question, what exactly is Enterprise Content Management? The simple answer is that it is the business or process of extracting useful information from objects such as emails and PDFs and Word documents and then using that information in a business process. It is all about the process of capturing Metadata and content in the most accurate and expeditious manner possible so we can automate business processes as much as possible.

If done properly, it makes your job more pleasant and saves your organization money and it makes your customers and suppliers happier. As such it sounds a lot like motherhood (who is going to argue against it?) but it certainly isn’t like manna from heaven. There is always a cost and it is usually significant. As always, you reap what you sow and effort and cost produces rewards.

Is content management something you should consider? The answer is definitely yes with one proviso; please make sure that the benefits are greater than the cost.

 

Could you manage all of your records with a mobile device?

by Frank 2. September 2012 06:00

I run a software company and I design and build an enterprise strength content management system called RecFind 6 which among other things, handles all the needs of physical records management.

This is fine if I have a big corporate or government customer because the cost is appropriate to the scale of the task at hand. However it isn’t fine when we receive lots of inquiries from much smaller organizations like small law forms that need a records management solution but only have a very small budget.

A very recent inquiry from a small but successful engineering company was also a problem because they didn’t have any IT infrastructure. They had no servers and used Google email. However, they still had a physical records management problem as well as an electronic document management problem but our solution was way outside of the ballpark.

Like any businessman I don’t like to see business walk away especially after we have spent valuable consultancy time helping the customer to understand the problem and define the need.

We have had a lot of similar inquiries lately and it has started me thinking about the need for a new type of product for small business, one that doesn’t require the overhead and expense of an enterprise-grade solution. It should also be one that doesn’t require in-house servers and a high overhead and maintenance cost.

Given our recent experience building a couple of iOS (for the iPhone and iPad) and Android (for any Android phone or tablet) apps I am of the opinion that any low cost but technically clever and easy-to-use solution should be based around a mobile device like a smart phone or tablet.

The lack of an in-house server wouldn’t be a problem because we would host the solution servers at a data centre in each country we operate in. Programming it wouldn’t be a problem because that is what we do and we already have a web services API as the foundation.

The only challenge I see is the need to get really creative about the functionality and the user interface. There is no way I can implement all the advanced functionality of the full RecFind 6 product on a mobile device and there is no way I can re-use the user interface from either the RecFind 6 smart-client or web-client. Even scaled down the user interface would be unsuitable for a mobile device; it needs a complete redesign. It isn’t just a matter of adapting to different form factors (screen sizes), it is about using the mobile device in the most appropriate way. It is about designing a product that leverages off the unique capabilities of a mobile device, not trying to force fit an application designed for Windows.

The good news is that there is some amazing technology now available for mobile devices that could easily be put to use for commercial business purposes even though a lot of it was designed for light weight applications and games. Three examples of very clever new software for mobile devices are Gimbal Context Aware, Titanium Mobile SDK and Vuforia Augmented Reality. But, these three development products are just the tip of the iceberg; there is literally a plethora of clever development tools and new products both in the market and coming to market in the near future.

As a developer, right now the Android platform looks to be my target. This is mainly because of the amount of software being developed for Android and because of the open nature of Android. It allows me to do far more than Apple allows me to do on its sandboxed iOS operating system.

Android also makes it far easier for me to distribute and support my solutions. I love iOS but Apple is just a little too anal and controlling to suit my needs. For example, I require free access to the file system and Apple doesn’t allow that. Nor does it give me the freedom I need to be able to attach devices my customers will need; no standard USB port is a huge pain for application developers.

I am sorry that I don’t have a solution for my smaller customers yet but I have made the decision to do the research and build some prototypes. RecFind 6 will be the back-end residing on a hosted server (in the ‘Cloud’) because it has a superset of the functionality required for my new mobile app. It is also the perfect development environment because the RecFind 6 Web Services SDK makes it easy for me to build apps for any mobile operating system.

So, I already have the backend functionality, the industrial-strength and scalable relational database and the Web Services API plus expertise in Android development using Eclipse and Java. Now all I have to do to produce my innovative new mobile app is find the most appropriate software and development platforms and then get creative.

It is the getting creative bit that is the real challenge. Wish me luck and watch this space.

 

Are you addressing the symptoms or the problem?

by Frank 19. August 2012 06:00

We are a software company building, selling and supporting our product RecFind 6 as an information management system and enterprise content management system. We have an in-house support department (we don’t outsource anything) and thousands of customers that contact it with questions and reports of problems they are having.

However, like I suspect happens at most software vendors, it is often very difficult for my support people to initially diagnose the real problem. Obviously, if there is an error message then it is easier to resolve but in most cases there is no error message, just an explanation of what a user thinks is the product not working properly.

If we can connect in to the user’s workstation using GoToAssist then we can usually ‘see’ firsthand what the problem is and then help the customer. However, this is not always possible and in a lot of cases my people are working ‘blind’ via phone or email and the only recourse is a question and answer dialog until we get to the point where we can define what the user thinks is going wrong and we can get the history of the problem. That is “When did it start to happen? What changed? Does it happen with everyone or just some users?” Etc., etc.

My people are pretty good at this process but even they get caught occasionally when the customer describes what he/she thinks the solution is rather than what the problem is. This usually takes the form of the customers telling us the ‘fix’ we need to make to the product to solve his/her ‘problem’. The wise support person will always ask, “What were you trying to do?” Once you can determine what the customer was trying to do, you then understand why they are asking for the particular ‘fix’. In most cases, the real problem is that the customer isn’t using the right functionality and once shown how to use the right functionality the need for a ‘fix’ goes away.

Problems also arise when my support people start mistakenly addressing the symptoms instead of the problem. In all fairness, it is often hard to differentiate the two but you can’t fix a problem by addressing the symptoms; you have to go back further and first define and then fix the root problem. Once the root problem is fixed the symptoms magically disappear.

For example, a customer reports multiple documents being created with the same auto number (i.e., duplicate numbers) as a problem. This isn’t really the problem though that is how the customer sees it. It is in fact a symptom and a clue to the identification of the real problem. In the above example, the root problem will be either an auto-number algorithm not working properly or an auto-number configuration with a flawed design. The former is what we call a ‘bug’ and the latter is what we call ‘finger trouble’; the configured auto number configuration was working precisely as designed but not as the customer intended.

Bugs we fix in code but finger trouble we fix by first clearly understanding what the customer wants to achieve and then by helping them to configure the functionality so its works as expected.

All experienced support people get to know the difference between:

What the customer thinks is the solution versus the problem; and

The symptoms versus the problem.

In my experience these are the two most common challenges faced when handling support calls. Recognizing both as early as possible is critical to achieving a speedy resolution and minimizing frustration. Not recognizing both as early as possible leads to longer resolution times and unhappy customers.

If we extend our support experience to real life we realize that these same two challenges face us in everyday life and in all of our social interactions. It why we often argue at cross-purposes; each party seeing the problem differently because of different perceptions of what the real problem is.

The challenges of misunderstanding are also often harder to overcome in real life because unlike a support call which has form and structure, our social interactions are mostly unstructured and opportunistic. We don’t start with a problem, we start with a casual dialog and don’t realize we are about to enter a conflict zone until it sneaks up upon us.

So if you find yourself in an argument please take pause and take the time to ask yourself and the other party, “Just what is it exactly we are arguing about?”  Which upon reflection, is exactly how we should handle each and every support call.

If we take the time to properly define the real problem we would spend far less time arguing and making people unhappy and far more time enjoying the company of our customers and friends. It is a no-brainer really, who wants to go through life in constant conflict?

For my part, I will just continue to ask to ask, “Before I address your request for a change would you mind please explaining what you were you actually trying to achieve; can you please show me?” And “What were you doing when you first saw that problem? Please start from the beginning and walk me through the process.” These two questions have worked for me for a very long time and I certainly hope that they work for you.

 

Is Information Management now back in focus?

by Frank 12. August 2012 06:00

When we were all learning about what used to be called Data Processing we also learned about the hierarchy or transformation of information. That is, “data to information to knowledge to wisdom.”

Unfortunately, as information management is part of what we call the Information Technology industry (IT) we as a group are never satisfied with simple self-explanatory terms. Because of this age-old flaw we continue to invent and hype new terms like Knowledge Management and Enterprise Content Management most of which are so vague and ill-defined as to be virtually meaningless but nevertheless, provide great scope for marketing hype and consultants’ income.

Because of the ongoing creation of new terminology and the accompanying acronyms we have managed to confuse almost everyone. Personally I have always favoured the term ‘information management’ because it tells it like it is and it needs little further explanation. In the parlance of the common man it is an “old un, but a good un.”

The thing I most disliked about the muddy knowledge management term was the claim that computers and software could produce knowledge. That may well come in the age of cyborgs and true artificial intelligence but I haven’t seen it yet. At best, computers and software produce information which human beings can convert to knowledge via a unique human cognitive process.

I am fortunate in that I have been designing and programming information management solutions for a very long time so I have witnessed first-hand the enormous improvements in technology and tools that have occurred over time. Basically this means I am able to design and build an infinitely better information management solution today that I could have twenty-nine years ago when I started this business.  For example, the current product RecFind 6 is a much better, more flexible, more feature rich and more scalable product than the previous K1 product and it in turn was an infinitely better product than the previous one called RecFind 5.

One of the main factors in them being better products than their predecessors is that each time we started afresh with the latest technology; we didn’t build on the old product, we discarded it completely and started anew. As a general rule of thumb I believe that software developers need to do this around a five year cycle. Going past the five year life cycle inevitably means you end up compromising the design because of the need to support old technology. You are carrying ‘baggage’ and it is synonymous with trying to run the marathon with a hundred pound (45 Kg) backpack.

I recently re-read an old 1995 white paper I wrote on the future of information management software which I titled “Document Management, Records Management, Image Management Workflow Management...What? – The I.D.E.A”. I realised after reading this old paper that it is only now that I am getting close to achieving my lofty ambitions as espoused in the early paper. It is only now that I have access to the technology required to achieve my design ambitions. In fact I now believe that despite its 1995 heritage this is a paper every aspiring information management solution creator should reference because we are all still trying to achieve the ideal ‘It Does Everything Application’ (but remember that it was my I.D.E.A. first).

Of course, if you are involved in software development then you realise that your job is never done. There are always new features to add and there are always new releases of products like Windows and SQL server to test and certify against and there are always new releases of development tools like Visual Studio and HTML5 to learn and start using.

You also realise that software development is probably the dumbest business in the world to be part of with the exception of drug development, the only other business I can think of which has a longer timeframe between beginning R&D and earning a dollar. We typically spend millions of dollars and two to three years to bring a brand new product to market. Luckily, we still have the existing product to sell and fund the R&D. Start-ups however, don’t have this option and must rely on mortgaging the house or generous friends and relatives or venture capital companies to fund the initial development cycle.

Whatever the source of funding, from my experience it takes a brave man or woman to enter into a process where the first few years are all cost and no revenue. You have to believe in your vision, your dream and you have to be prepared for hard times and compromises and failed partnerships. Software development is not for the faint hearted.

When I wrote that white paper on the I.D.E.A. (the It Does Every Thing Application or, my ‘idea’ or vision at that time) I really thought that I was going to build it in the next few years, I didn’t think it would take another fifteen years. Of course, I am now working on the next release of RecFind so it is actually more than fifteen years.

Happily, I now market RecFind 6 as an information management solution because information management is definitely back in vogue. Hopefully, everyone understands what it means. If they don’t, I guess that I will just have to write more white papers and Blogs.

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.

Have you considered Cloud processing? There are significant benefits

by Frank 6. May 2012 06:00

Most of us have probably become more than a little numbed to the onslaught of Cloud advertising and the promotion of the ‘Cloud’ as the salvation for everyone and the panacea for everything. The Cloud is promoted by its aggrandizers as being both omnipotent and omniscient; both qualities I only previously associated with God.

This is not to say that moving business processing to the Cloud is not a good thing; it certainly is. I just wish that the promoters would tone down the ‘sell’ and clearly explain the benefits and advantages without the super-hype.

Those of us with long memories clearly recall the early hype about what was then called ASP or Application Service Processing or even Application Service Provider. This was the early progenitor of the Cloud and despite massive hype it did not fly. The reasons were simple, neither the technology nor the software (application and system) were up to the job. Great idea, pity it was about five years before its time.

Unfortunately, super-hype in our industry is usually associated with immature and unproven technology. Wiser, older people nod sagely and then wait a few years for the technology to catch up with the promises.

As an older (definitely) and wiser (hopefully) person I am now ready to accept that all the technology required for successful and secure Cloud processing is now available and proven; albeit being ‘improved’ all the time so still take care not to rush in with experimental technology.

As with many new technologies the secret is KISS; Keep It Simple Stupid. If it seems too complex then it is too complex. If the sales person can’t answer all of your questions clearly and unambiguously then walk away.

Most importantly, make sure you know all about all of the parties involved in the transaction. For example:

1.    What is the name of the data centre?

2.    Where is it located?

3.    Who ‘owns’ the rack and equipment and software at the data centre?

4.    What are the redundant features?

5.    What are the backup and recovery options?

6.    Is your vendor the owner of the co-hosted facility or do they subcontract to someone else? If they sub-contract is the company they subcontract to the owner or are they too just part of a chain of ‘hidden’ middle-men? It is critical for you to understand this chain of responsibility because if something goes wrong you need to know who to chase.

There are a lot more questions you need to ask but this Blog isn’t the place to list them all. I am sure your IT team and application owners will come up with plenty more. If they don’t, wake them up and demand questions.

Most small to medium organizations today simply do not have the time or expertise to run a computer room and manage and maintain a rack of servers. There is also a dearth of ‘real’ expertise and a plethora of phonies out there so hiring someone who is actually smart enough to manage your critical infrastructure is a very difficult exercise made more so by most business owners and managers simply not understanding the requirements or technology. It often becomes a case of the blind hiring the almost blind.

Most small to medium enterprises also cannot afford the redundancy required to ensure a stable and reliable infrastructure. A fifteen minute UPS is no substitute for a redundant bank of diesel generators and a guaranteed clean power supply.

Why should small to medium enterprises have to buy servers and networks and IT support? It isn’t part of their core business and this stuff should not be weighing down the balance sheet. Why should they be devoting scarce and expensive management time to activities that are not part of their core business?

In-house computer rooms will soon be become as rare as dinosaurs and this is how it should be, they are an anachronism in this time and age; out of time and out of place.

All smart and business savvy small to medium organizations should be planning to progressively move all their processing to the Cloud so as to lower costs, improve service levels and reduce management stress. I say progressively because it is still wise to get wet slowly and to take little steps. Just like with your first two-wheel bicycle, it pays to practice with the training wheels on first. That way, you usually avoid those painful falls.

I like to think I am a little wiser because I still have scars from gravel rash when I was a kid. I am moving my RecFind 6 customers to the Cloud and I am moving my in-house processing to the Cloud but just like you, I am doing it slowly and carefully and triple-checking every aspect. I don’t take risks with my customers or my business and neither should you.

One last thing, I have the advantage of being very IT literate and of having a top IT team working for me so we have the in-house expertise required to correctly evaluate and select the most appropriate technology and options. If you do not have this level of in-house IT expertise then please take extra care and try to find someone to assist who does have the level of IT knowledge required. Once you sign up, it is too late. Buyer’s remorse is not a solution to any problem.

Are you running old and unsupported software? What about the risks?

by Frank 29. April 2012 20:59

Many years ago we released a 16 bit product called RecFind version 3.2 and we made a really big mistake. We gave it so much functionality (much of it way ahead of its time) and we made it so stable that we still have thousands of users.

It is running under operating systems like XP it was never developed for or certified for and is still ‘doing the job’ for hundreds of our customers. Most frustratingly, when we try to get them to upgrade they usually say, “We can’t justify the expense because it is working fine and doing everything we need it to do.”

However, RecFind 3.2 is decommissioned, unsupported and, the databases it uses (Btrieve, Disam and an early version of SQL Server) and also no longer supported by their vendors.

So our customers are capturing and managing critical business records with totally unsupported software. Most importantly, most of them also do not have any kind of support agreement with us (and this really hurts because they say they don’t need a support agreement because the system doesn’t fail) so when the old system catastrophically fails, which it will, they are on their own.

Being a slow learner, ten years ago I replaced RecFind 3.2 and RecFind 4.0 with RecFind 5.0, a brand new 32 bit product. Once again I gave it too much functionality and made it way too stable. We now have hundreds of customers still using old and unsupported versions of RecFind 5.0 and when we try to convince them to upgrade we get that same response, “It is still working fine and doing everything we need it to do.”

If I was smarter I would have built-in a date-related software time bomb to stop old systems from working when they were well past their use-by date. However, that would have been a breach of faith so it is not something we have or will ever do. It is still a good idea, though probably illegal, because it would have protected our customers’ records far better than our old and unsupported systems do now.

In my experience, most senior executives talk about risk management but very few actually practice it. All over the world I have customers with millions of vital business records stored and managed in systems that are likely to fail the next time IT updates desktop or server operating systems or databases. We have warned them multiple times but to no avail. Senior application owners and senior IT people are ignoring the risk and, I suspect, not making senior management aware of the inevitable disaster. They are not managing risk; they are ignoring risk and just hoping it won’t happen in their reign.

Of course, it isn’t just our products that are still running under IT environments they were never designed or certified for; this is a very common problem. The only worse problem I can think of is the ginormous amount of critical business data being ‘managed’ in poorly designed, totally insecure and teetering-on-failure, unsupportable Access and Excel systems; many of them in the back offices of major banks and financial institutions. One of my customers called the 80 or so Access systems that had been developed across his organization as the world’s greatest virus. None had been properly designed, none had any security and most were impossible to maintain once a key employee or contractor had left.

Before you ask, yes we do produce regular updates for current products and yes we do completely redesign and redevelop our core systems like RecFind about every five years to utilize the very latest technology. We also offer all the tools and services necessary for any customer to upgrade to our new releases; we make it as easy and as low cost as possible for our customers to upgrade to the latest release but we still have hundreds of customers and many thousands of users utilizing old, unsupported and about-to-fail software.

There is an old expression that says you can take a horse to water but you can’t make it drink. I am starting to feel like an old, tired and very frustrated farmer with hundreds of thirsty horses on the edge of expiration. What can I do next to solve the problem?

Luckily for my customers, Microsoft Windows Vista was a failure and very few of them actually rolled it out. Also, luckily for my customers, SQL Server 2005 was a good and stable product and very few found it necessary to upgrade to SQL Server 2008 (soon to be SQL Server 2012). This means that most of my customers using old and unsupported versions of RecFind are utilizing XP and SQL Server 2005, but this will soon change and when it does my old products will become unstable and even just stop working. It is just good luck and good design (programmed tightly to the Microsoft API) that some (e.g., 3.2) still work under XP. RecFind 3.2 and 4.0 were never certified under XP.

So we have a mini-Y2K coming but try as I may I can’t seem to convince my customers of the need to protect their critical and irreplaceable (are they going to rescan all those documents from 10 years ago?) data. And, as I alluded to above, I am absolutely positive that we are only one of thousands of computer software companies in this same position.

In fairness to my customers, the Global Financial Crisis of 2008 was a major factor in the disappearance of upgrade budgets. If the call is to either upgrade software or retain staff then I would also vote to retain staff. Money is as tight as it has ever been and I can understand why upgrade projects have been delayed and shelved. However, none of this changes the facts or averts the coming data-loss disaster.

All over the world government agencies and companies are managing critical business data in old and unsupported systems that will inevitably fail with catastrophic consequences. It is time someone started managing this risk; are you?

 

The importance of partnering in the new online sales paradigm

by Frank 25. March 2012 06:00

A company’s website is said to be its window to the world. It is supposed to be the portal through which business flows in from all corners of the globe. (Now that is a silly expression, since when did a globe have corners?) Notwithstanding the silly expression, the Internet and a company’s website are supposed to be the foundation of the modern marketing paradigm. In this new model, everything will be sold online and Cloud and SaaS will be the most used and abused marketing terms.

However, there are a couple of minor flaws in this model.

Have you ever tried to do an online demonstration or presentation to 27 people, all with different agendas? I have and it is almost impossible to be effective in this environment.

Have you ever tried to understand the nuances of a complex commercial application requirement using only the telephone, email and online sessions? I have and it is impossible to really understand one hundred-percent of the requirement.

Sure you can sell books and computers online but it is a far from perfect model when selling complex application systems that will eventually be integral to the successful operation of your customer’s business.

In our business we make good use of technology to better communicate with our customers and prospects all around the world. We in fact couldn’t operate without the Citrix tools GoToAssist, GoToMeeting and GoToTraining. They, or tools like them, are essential for running a software and services company like ours with customers all around the world.

In this day and age, and especially after the GFC, no company can afford to have ‘local’ staff in every town, state or country where it does business. Nor can any company, no matter how big, afford to fly pre-sales staff in for every one-hour demo requested by a prospect or every one or two hour support session for a customer.

However, in our sales cycle (application software) there are still many things that are best done face to face and there are some things, like application consulting, that can only be done face to face.

At this time we handle the face to face requirement by telling people we hire for consulting and support jobs that they must be available to travel and frequently, both inter-state and internationally. We make this requirement a prominent part of the job add and the interviews. Having a ‘flying squad’ of support people and application consultants is now an integral and essential part of our sales paradigm and from the customer’s viewpoint it works very well. But, it is a far from perfect solution from our viewpoint because of the high cost and lost time or ‘opportunity-cost’ of dead time spent in transit.

The flying squad will always be an important tool for us when delivering solutions but as we grow it needs to be supplemented and complemented by partnerships with local firms with the skillsets our customers require.

A few years ago, conscious of this need to partner, I registered a new website called bizzpartnerships.com with the intention of starting a new business primary designed to locate and connect business partners all around the globe. Sadly, the pressure of running and growing this business didn’t leave me much time and like a lot of good ideas, it is gathering dust.

It is still a great idea because there are literally millions of businesses like mine that need partners to both win and support customers; partners that can provide that essential face to face contact that is sorely missing from most modern business models. It fact, the situation worsens year by year as vendors cut costs and outsource almost every function to countries like India, China and the Philippines. I stopped dealing with a well-known hardware vendor because they told me my account manager would no longer be local but would be based in a call centre in India. I have gone from spending millions with this company to spending absolutely nothing.

Notice I am not talking about outsourcing, which I hate, but partnering, which I love. Anyone who wants to know how I feel about outsourcing should read one of my previous Blogs:

http://www.knowledgeonecorp.com/blog/post/2012/02/05/Outsourcing-will-destroy-the-west.aspx

Partnering provides that much needed and much appreciated local, face to face contact; outsourcing takes it away.

My prime objective from this point on will be to forge partnerships with companies that can add value to my customers. I believe that this is an essential component of the still maturing online model.

So, if you are reading this blog and you are part of or know of a quality customer-centric services company that can add value to an enterprise content management software installation then please let me know about it. In a good partnership, everyone benefits, especially the customer.

Month List