Blog

CogniBlog

Thoughts from the Cognidox world
Tags >> Document Management Systems

The analysis and research company Basex published a survey this week entitled "The Document Jungle". It is a survey of the documentation habits of 300 knowledge workers.

They reported that each person produces 1 or 2 short documents per day and were called on to review around 3 to 5 documents per week. Some documents are not sent for review or sent to just one co-worker. The majority are circulated for review.

When it comes to circulating documents for review, 60% of the time they are sent as email attachments. The outcome may sound familiar to you - comments come back and have to be manually collated by the editor; there is a high percentage of error as edits get missed or comments overlooked; and comments are not returned in a timely manner.

25% of the survey respondents deliberately leave colleagues off review lists as they know they will slow down the review process. Personal experience tells us that, in the rush to get a major design document ready for a review deadline, it isn't easy to focus on the big picture of why we wanted it reviewed in the first place. "Speak now or forever hold your peace" isn't a very good design strategy, believe it or not.

We have a strong set of features in CogniDox to support the document review workflow, but we are frequently asked by users to include more. In the latest release (v8.2), for example, we added a better way for project leads to obtain reports on the status of documents sent out for review and/or approval. I can create a spreadsheet report by user that shows how many documents they've been asked to review, how many are outstanding (and are overdue on deadlines). I can do the same thing for document approvals.

It's a handy little dashboard-type report that gives even better feedback in larger companies with complex inter-departmental relationships. Routing every design document through a small set of design architects may show up in the stats - these individuals have a large review workload and they are not able to keep up. Good supporting data for your next New Hire request application...

Here are 8 suggestions for how to improve design document reviews in your company:

  1. Get a Document Management System instead of using e-mail attachments. You have a very low probability of success in improving your document review process using an email-based solution.
  2. Think before you add people to your list of reviewers. Do you really want them to comment, or are you just notifying them that the document is available? CogniDox separates reviewers from people to be notified - use it explicitly.
  3. Use the comments field to direct your reviewers. Are you more concerned about technical accuracy in this issue than you are about editorial style? I need to know that as a reviewer. It may make sense to assign sections to individual reviewers - make that explicit.
  4. Set meaningful deadlines. If you really need the draft press release reviewed by the end of one working day, say so.
  5. Use email to send notifications that documents are ready for review. Include URL links that enable reviewers to quickly and easily navigate to the document review pages in your DMS. It may help to encourage timely reviews if people can see that other reviewers are making progress on their review tasks. Send automated 'nagging' mails when deadlines are missed.
  6. Agree a set of terms applicable to your workgroup, department or (ideally) your company. If I reject your draft document and request changes, is that the same as if I accept your draft but leave a set of comments that I expect you to consider and include?
  7. It's easier to read review history comments when displayed "in-line" by version and contributor threads. CogniDox allows users to select a document version and read the threads of comments made on each. Other tools such as Google Wave are addressing the same opportunity.
  8. Build accountability into the document review process. Make document readiness an explicit part of any new Product Gate Process or QA strategy. Remember, poor documents end up costing extra time and money. Worse, customers may get to read them.

CMS Watch is a great site for learning about document management, web content management, enterprise content management, enterprise portals, web analytics, and enterprise search solutions. It's mandatory reading for those of us making products, and definitely worth the time of any buyer who needs to select a product in this area.

This week they published their predictions for what is likely to happen in 2010. They were also brave and smart enough to assess how well their 2009 predictions fared.

Selectively looking at some of their 2009 outcomes, they probably got it right that Open Source ECM made advances and that social computing diffused into the Enterprise. I think they got it more wrong than they admit on SharePoint being derailed by Office 14  - the interest continued unabated and the beta of SharePoint 2010 did it no harm either.

They predicted that SaaS vendors would expand offerings. There was plenty of activity in the SaaS sector but many buyers are still unconvinced about putting company documents on a third party server. A term of service from a SaaS provider looked at recently is not uncommon: "Once you cancel or terminate your registration with us, we will instantly delete data, content, text, documents, images and information from the service. After the cancellation of the service, all of your content will be lost for ever." Data lock-in as a variant on vendor lock-in, and just as dangerous. 


For 2010, CMS Watch makes some predictions that we can compare and assess in regard to CogniDox.

For example, "Enterprise Content Management and Document Management will go their separate ways" (#1) gets our agreement. There is a tension between providing good workflow tools for document management and the tools used for website publishing. Clearly they need to be compatible and work in unision at some point but doing both in one application isn't necessarily the best idea. Given that prediction, their "Document Services will become an integrated part of ECM" (#8) may seem to be a contradiction. Ignoring that, we'd agree that helping users to automate the production of documents will be helpful and important. We tend to describe this as "document assembly" which I think is a more specific and useful term for e.g. creating a new legal document using metadata to populate key fields.

We'd also agree that "Faceted search will pervade enterprise applications" (#2). They mention Lucene/Solr, which we support in CogniDox 8.0 onwards, but we'd also mention the Xapian open source search engine library and the Flax Search Service as a technology to watch. CMS Watch only mentions SharePoint in the context of "Digital Asset Management vendors will focus on SharePoint integration over geographic expansion" (#3) which may be overly specific - most ECM and WCM companies will consider offering a SharePoint connector. That doesn't however imply that SharePoint is any more than a workgroup Intranet builder with file sharing capability. Buying decisions may verge on the ridiculous - why pay $$ for SharePoint user licenses and then add $$$$ for a proprietary ECM add-on? But SharePoint 2010 will be a force, and we can anticipate a rush on products that see themselves as SharePoint 'killers'.

One thing that correlates with ECM suites and SharePoint is that they can bring hidden costs in hardware / server requirements and the IT admin effort inherent in their client/server architectures. For that reason we'd agree that "Enterprises will lead thick client backlash" (#6) and to a lesser extent that "Cloud alternatives will become pervasive" (#7). Some of the same issues faced in 2008/9 for SaaS still remain.

We'd strongly agree that "Gadgets and Widgets will sweep the Portal world" (#9). People have become accustomed to seeing them on the public web at sites like iGoogle and they will become the definitive user interface for the Intranet. The only question is what widgets are the most essential?

The prediction that "Mobile will come of age for Document Management and Enterprise Search" (#4) depends on what is meant by "coming of age". It will certainly be the case that this will grow from the current small base, but we think this is one for 2011 instead.

That leaves 4 other predictions we have not commented on, and so a quick visit to CMS Watch to read these for yourself is recommended.


We recently released CogniDox 8.1 and amongst the new features was a CogniDox Word Add-in. 

An Add-in is a software component that adds custom commands and new features to a primary program such as those in the Microsoft Office suite. The particular value of the CogniDox Word Add-in is that you can browse and issue commands to the CogniDox repository while you are using Word.

The first elementary fact we faced is that the Office suite is a collection of individual programs and we had to choose which one we wanted to extend. We've blogged recently on the ongoing ubiquity of Microsoft Word as the principal tool for knowledge workers, so it stood out from e.g. Powerpoint and Excel as the one to go for.

Everyone knows there are multiple versions of Office in use across the market. Ideally, we'd support all of them. Unfortunately, the differences between Office 2003 and 2007 makes that two quite separate tasks rather than one. It isn't easy to find out what share of users are using Office 2007 compared to older versions - there's a stat from Forrester that  roughly 80% are using the latest version (2007). This seems on the high side, but then when you consider that new PCs will be shipped with the latest version and that 80% of Microsoft's Business Division revenue comes from Office B2B sales, perhaps it isn't so far out. I have to say we're still not fully convinced though.

So we choose Word 2007. Worst case scenario, everyone plans to upgrade to it and our work is re-usable for Office 2010. Having to support 2003 would have eaten into development time for a product that will become less relevant to our user base.

The next issue was how to tool ourselves for the task. MSDN tools have been prohibitively expensive. Luckily, a year ago Microsoft launched a program for new start-ups that would allow them access to MSDN on a very reasonable basis. You need to satisfy certain start-up criteria - in business for less than 3 years with under $1M in revenue for example, and you have to be nominated by a Network Partner (often a VC or a BA group). But that gets you participation for up to three years and access to  Visual Studio, Windows Server, SQL Server, SharePoint, MSDN, Microsoft Office and more.

We joined BizSpark in mid 2009 through the assistance of our local friendly and capable Business Leaders Network (BLN). With the help of their registration code it was really simple to do.

Once we had access to all these development tools we had to decide which ones to use. We went for Visual Studio 2008 using C#. There's a strong argument to do Office development in VisualBasic.NET rather than C#, because a lot of the Office Interoperability API calls use optional parameters. This is not supported by C# 3.0. As a result, you tend to wind up with fairly verbose code. MS has a KB article about this. Visual Studio 2010 will bring in support for optional and named parameters, which will make working with the Office Interop APIs much more pleasant. As the Add-in is a relatively small project; we prefer C# much more than VB and VS 2010 will bring improvements, therefore we went C#.

At the protocol level, our interactions with the Add-in are via SOAP. CogniDox already had a SOAP interface used by our Linux command line client, so we were extending known functionality to provide a richer interface for the add-in. The benefit is we can reuse the SOAP API to do other integrations. CogniDox publishes its SOAP API using a Web Services Description Language (WSDL) file, and all it took to expose the API to the C# project was to point Visual Studio at the WSDL file URL.

This highlights the fact that Open Data formats can be as important as Open Source.

At the UI level we had to work with the ribbon UI and a custom task pane which are standard UI elements within Office 2007. One decision was between using the WPF (Windows Presentation Foundation) or WinForms for the UI controls. WPF is relatively new and set to be the future of of Windows UI development, but we went the WinForms route because it gave us access to more mature documentation that sped up development time. We may re-visit this decision with future releases of the Add-in. Our priority for the initial release was to explore where we could go with the Add-in and get some real user benefit out in the field.

So, at least one LAMP shop gets to develop for MS Windows. Without the existance of the Microsoft Bizspark program, it's highly unlikely that we would have chosen to do that or be able to fund it.


I've been using the term "knowledge workers" frequently in recent posts, so maybe it's overdue a definition. Here's a recent quote from McKinsey analysts that I find useful:

"The heart of what knowledge workers do on the job is collaborate, which in the broadest terms means they interact to solve problems, serve customers, engage with partners, and nurture new ideas." -- McKinsey report, October 2009

CogniDox is used by companies that make high-tech products - semiconductors, electronics and similar - and so it’s clear that the average user in these companies fits well with this definition.

Over the year, we’ve taken a high level view over an amalgam of many companies that are storing files in a CogniDox repository to see what tools they use when performing their knowledge worker tasks. It’s not a rigorous scientific study by any means, but the results do seem consistent.

What we found is that Microsoft Office Word is still the tool of choice for capturing “what’s important” for these product design companies. For companies with many 10s of 1000s of documents in the repository, Word files were over half of the total stored (56%). The other format that is clearly important is PDF. CogniDox automatically generates PDFs from file formats such as Word and PowerPoint, but even after allowing for these ‘duplicates’ we still saw that PDFs make up over a quarter of the total (26%).

There are pockets of OpenOffice in use, especially among the engineering teams in our sample, but this would be consistent with the market share estimates of OpenOffice.org i.e. 10-20%. In any event, the main application is Writer and it is being used as a straight substitute for Word to serve the same purpose in documentation.

Other Microsoft Office applications came in as follows: Excel (6%), PowerPoint (4%), Project (1%) and Visio (1%). The rest were typically the outputs of specialist teams such as software (zips, tar files, etc) and technical authoring (XML).

Of course quantity isn’t directly correlated with importance. One of those Visio diagrams or Project plans may have taken far more effort and be considered more vital than a bunch of Word files.

This also isn’t a measure of software application usage – I’d expect email clients (Outlook, Thunderbird) and Browsers (IE, Firefox, etc) to figure large in that. This has more to do with the intersection between applications used and file storage.

Note this does not capture the knowledge worker's other modes of collaboration - surveys show the telephone and face-to-face meetings are still the preferred means of collaboration. People love their meetings. I've quoted two other surveys in previous posts that tell us the average time spent on meeting is 1hr 30mins per day, but if you are a Product Manager you could be attending up to 15 meetings per week - at least 3 hours per day of their time.

When meetings are not possible, e-mail and attachments fill the gap across the boundaries of time and location. However, the knowledge workers we analysed would possess in-boxes containing thousands of valuable content files as attachments, if email was the only option.

There wasn’t much evidence of the repository being used for multimedia files – no large image or video libraries. Probably not surprising given the nature of the enterprises and I’d expect different from e.g. a media creative company. Pity, as there’s huge untapped potential for using short (5 min) videos to assist product development – visual bug reports being an example.

There is also potential for Enterprise 2.0 tools in collaboration – but the reality seems to be that we are not using them yet. There’s no reason why that won’t change over time as teams increasingly collaborate using Wikis, micro-blogging and other tools. There may be good reasons to use Facebook for social networking or LinkedIn for business networks, but it has yet to make a case for internal knowledge worker networking.

But it will stay true that a key part of a product developer’s responsibilities is to document the product, and keep a safe record.

And Microsoft Office Word is still their preferred way to do the former.


This week we made our quarterly release of software, which we labeled version 8.0 (as opposed to 7.x) because (a) there were substantial changes to the internal architecture to support search engine plugins, and (b) it has a re-worked configuration system which makes life easier for CogniDox sysadmins.

The headline feature was therefore the fact that user companies can select between using the 'classic' Swish-e or the Apache Solr search engine. We've blogged in the past about Enterprise Search, so I'll just summarise to say that Solr offers features such as frequent incremental indexing, federated search, ‘more like this’ searches and spelling suggestions when no results are found. All of which combine into a single benefit - one search has a far greater probability of giving you useful results.

We also support a third search plugin in Flax Search Services, which is based on Xapian. FSS is still in-development, but it will be supported when it is ready for showtime within months. As we've said before, this is promising technology. Solr on the other hand has the power of the Apache brand. It shows how far F/OSS has come when I can say 'brand' in this context :-)

I've also blogged before about another feature - better document import - so I'll also gloss over that apart from saying that it feels good to rip out a feature and start again when it brings good usability improvements.

For ages now we've stopped using Microsoft Office Project (too expensive) and have been looking at open source alternatives. We've used GanttProject and and OpenProj for task scheduling and resource levelling. It's fair to say we do a lot less of this now than in the past - less spread out geographically, smaller development groups and an Agile methodology explains why - but it still comes in handy when you need to juggle constraints. In the v8.0 release support is provided for GanttProject, an alternative to Microsoft Project that provides project scheduling and management for Linux, Windows and MacOS X users. CogniDox includes an example PDF converter script for GanttProject .gan files. There isn't much to choose between the two mentioned, but GanttProject can import and export to MS-Project .mpx and .xml file formats whereas OpenProj only has save as .xml.

Another open source project we use is FreeMind, a free open source mind mapping application that allows a user to capture relationships as a diagram that represents ideas arranged around a central concept. CogniDox v8.0 can render FreeMind .mm files into Flash movies as the viewable version of the document. Mind mapping is one of those things that people either love or hate. One of the big 'preparation tasks' that companies face before they introduce a document categorisation system is to decide what are the information categories. We tried doing this using outline tools but it just seemed more natural to use a mind map where you start with "My Company" in the middle and then add departments, products, projects and anything else that made sense as links. So we've experimented with FreeMind as an Information Architect support tool. But it also has merit for animating a process or workflow, and that's what we are doing when we create a Flash movie from the static map. It also allows you to create linked maps, so you could create a procedure that links you to the appropriate content in CogniDox or on other systems.

Finally, there was the usual crop of small features that were direct requests from the user base. One was worthy of note: the weekly reminder email to users now includes a useful project collaboration feature – it reports on outstanding document review and approval requests from other users on shared documents. The use case for this is when you are preparing for a product or project gate review - if there are outstanding un-issued or un-approved documents you may decide to cancel the gate review until these are done as you would fail the gate criteria until this is so.

Integrating open source technologies such as Solr, Flax, GanttProject and FreeMind with CogniDox to create a platform of useful tools reminds me of a fundamental difference between proprietary and open source products. 

Proprietary software is nearly always 'streaky' - excellent modules mixed with so-so efforts. In the overall interest of the product's reputation, any concerns about these efforts are frequently supressed or denied. When you merge open source projects into one integrated whole, you can be as objective as you like about the module you are integrating. If you get it wrong, you jettison it and find a replacement. You don't need to have a 'tiger team', or the issues of managing out under-performing contributors. To paraphrase the CSI TV show, its all about the code.


Where Does The Day Go?

Posted by: paul

Back in 2003, researchers at the School for Information Management and Systems at UC Berkeley published a fascinating study entitled "How Much Information" that attempted to measure how much information was available in the world (then). It broke down the data by individual media such as TV, Newspapers, Internet, etc.

In TV for example, 21,000 TV stations around the world broadcast 123 million total hours on air every year. Even if 75% of content shown was repeat programming, that still leaves 31 million hours of original content. However, if every home in the world had access to 100 channels and every viewer watched 4 hours/day, then only around 3% of original content is being watched in total.

There is an update to their report that will inform us that each Information Worker in the USA now receives 1.6GB of information each day - emails, reports, blogs, texts, phone calls, etc.

It isn't difficult to see a parallel with the world of TV - that information may be out there but we are not taking it in. Unlike TV, information at work isn't something we are supposed to be able to ignore. It's all meant to be business-critical and we're expected to read and act on it. Some hope.

In fact, there is even going to be an Information Overload Awareness Day next month. In his blog, Jonathan Spira of Basex says there will be an event to mark the day. Cost to attend is $50, but delegates who promise not to multi-task (i.e. IM, e-mail, or text) during the event can get a 50% discount.

Basex have done interesting research to investigate in more detail where our day goes. According to them, the 'worst offender' is time lost to interruptions and recovery time from interruptions. These can be people interrupting in person or by phone, but we are as likely to allow ourselves to be interrupted by an incoming email, tweet or other enticing link. In fact, these non-time critical interruptions are more common. The problem with interruptions is that it takes ages to re-orient back to the original task. Once distracted, it can take 30 minutes to get back. No surprise, then, that interruptions (important or otherwise) total 2 hours and 14 minutes of lost productivity per day.

Another productivity drain is searching for information that you need to do your job. Basex say it takes 1 hour and 12 minutes per average day. Accenture did a survey of 1000 middle managers in 2007 and found that 2 hours per day was spent on search. The Accenture survey also added that 50% of the searches were useless, so that is another 35 minutes to 1 hour of lost productivity.

Meetings were the next big category of time spent in the average day. This takes 1 hour and 30 minutes per worker. Nobody really knows how productive is this time, but anecdotally nobody seems to have a good word to say about meetings. These days, most of them involve people who are busily being interrupted by emails anyway! It is typically the case that ad-hoc meetings with a loose agenda are the worst, so it follows that structured meetings with a clear agenda are the most productive. Roughly 45 minutes to 1 hour probably gets wasted on the wrong sort of meeting.

Another detailed analysis was done by IDC in their white paper on "The Hidden Costs of Information Work". Their breakdown is shown in the table below:

 

Average per Knowledge Worker

 

Most of the people employed by the companies who would use CogniDox are highly qualified, and an estimated cost is £250/day per employee (loaded rate).

The alarming conclusion from the Basex analysis is that one could be wasting 4 hours per day, or £125, on lost productivity for each knowledge worker.

The IDC study allows us to make an educated guess as to how much the right productivity tools, such as CogniDox, might help to improve productivity. A document management system ought to make a big difference to some tasks (e.g. manage document approval, search, file and organize documents) and at least a modest improvement to others (e.g. create documents would be faster using company templates, retrieving an image from an image library saves re-work).

Using a modest estimate, 24% of the cost per employee (£60 approx.) could be saved. In a company of 100 employees, that's £6000 per day.

It would take less than 2 days to re-coup the cost of a CogniDox license for 100 user subscriptions in an annual contract.

Companies are enduring huge pains to cut costs during this recession. It is amazing that any would be prepared to continue to allow wastage on this scale, when there is an alternative way to regain the lost hours of productive time.


Improving Document Import

Posted by: paul

One of the top issues in all Enterprise Software is that, no matter how good the software tool, unless it is widely used it is a waste of time and money.

"Shelfware", as it is known in IT circles.

If you purchase a top of the range CRM system to manage all your customer contact details and keep track of your relationships with them, it still falls into disuse unless your salesforce actually use it to record their visits and calls. In fact, 30% of CRM projects completely fail due to insufficient end-user involvement and buy-in.

You may persuade yourself that Business Process Modelling (BPM) will help you understand the critical workflows in the company, but again unless it is well-used and kept in a maintained state it won't deliver. The same is also true of Enterprise Resource Planning (ERP) software.

The core idea behind Document Management Systems (DMS) software is probably the centralized repository for all digital content. Again, unless users are depositing content into the repository, it won't deliver on the promises of saved costs and improved visibility.

It is extremely common to find yourself in a mixed-model where some content is in the DMS, while some is not. It could be that the missing content is legacy information, or it might be that it was once believed that the content didn't need to be included, but now you've changed your mind.

Making it easy to get that errant content into the repository is like an "amnesty" for users. It doesn't really matter about previous policy, because it can be changed with a swift document import.

We've been working to re-engineer the document import feature in CogniDox for exactly this reason. Coming up in Release 8.0.0, we've created a very minimal model where you can just import a zip file, and a slightly more detailed version where a control file will allow you to batch your requests and have them implemented in one execution. It's not that the feature wasn't there before 8.0.0; but rather that it's so much easier to use now.

I've already used it to upload all the minutes from a series of meetings that I realised would be better kept in CogniDox. Talk about not eating your own dog food! At least now I can quickly remedy my mistake.


Recently, I got around to reading the AIIM "State of the ECM Industry 2009" report published at the end of March. It's based on a survey of 568 respondents, with a majority (52%) from large organizations (1000+ employees). There was a high percentage (21%) of people from the local and national Government sector, and there was a distinct US & Canada (61%) skew.

What struck me about the report was that it could be seen as a prescription for smaller companies and startups, along the lines "This is what big companies don't like about themselves, you have an opportunity to do it differently". After all, one of the good things about a new startup is that you don't have to make the same mistakes.

It's easy to say, harder to do, but in my experience the degree of "start as you mean to go on" that smaller companies can muster is a good way to keep the growth curve as accelerated and smooth as possible. When you have to switch-in a new process or workflow, it can be a massively disruptive force at a time when you can least afford disruption. Of course, cost is a factor - many a person has left behind an expensive ERP system at their former company, unable to replace it in their new startup. But with the growing availability of Free and Open Source software packages, that isn't the only factor any more.

So what ails the larger Enterprise in their Content Management, and how can SMEs adapt this as guidelines for a better strategy?

By inverting the AIIM ECM findings, I'd say they are:

(1) Start with a low-cost strategy and keep to it - never think that you will switch to an expensive solution at some point in the future. Make other requirements such as compliance and legal discovery a sub-set of the cost saving requirement.

(2) Treat e-mail usage as a dangerous drug - if you become over-dependent you will find it impossible and/or expensive to quit. If e-mail attachments become the main method for communication, it will get out of control more quickly than you'd prefer.

(3) Don't allow documents to be buried. It isn't enough that it was ready by the deadline and reviewed at the meeting. It also has to be just as easy to find in 6 months time.

(4) Beware multiple solutions. It's easier to let two teams 'go their own way', but then very hard to re-integrate them. Keep asking why does it need to be different and whether anything can be done to integrate them across the top.

(5) Don't abdicate business solution decisions to IT only (even when it is a part time role done by one of the engineers or founders). This is as important as all your other strategic decisions, and it will have a very significant impact on your company culture.

(6) Get support directly from vendors rather than consultants. They have up-to-date knowledge and it is in keeping with low-cost guideline #1.

(7) Enterprise content will become a large repository quicker than you think, so the earlier you start to think about Enterprise search, the better.

(8) Blogs and wikis are useful, but remember they are content too and will need to be included in your records management.

I'm hardly neutral on this topic, but I don't see or accept why any startup or small company cannot develop a short strategy paper that sets out their business solutions needs and priorities. If they can't afford Oracle or SAP using third party implementers at this stage, it is totally not a problem. In fact, guideline #1 says it would be better to find an open source alternative.


We did an integration project with Verieda Ltd recently and issued a press release about it. Verieda is a new startup on the Cambridge scene and we met through the Cambridge Open Coffee network.

The interest in Register Management came from experiences in Embedded Software where we discovered that integrated software and silicon development was an essential rather than a luxury. Some of it was rooted in R&D methodologies and how the silicon design flow was integrated with the software development method. Most of it came down to person-to-person communication, IC design engineer and SW engineer working hand-in-hand throughout the project, and making sure that there were as few barriers as possible between the team members.

In many design meetings, once the top level functional blocks were understood, most of the work came down to the specific points of contact between software and hardware, and that was where the memory registers came in.

What was surprising back then was that there seemed to be very few tools to support this database-type problem. It often came down to an Excel spreadsheet that ended up as an appendix in the MS-Word specificication document. Not very maintainable, to say the least. And, in an industry where upstream design errors can have a massively expensive downstream impact, not a very robust error-checking strategy either. That need would seem to be addressed now by EDA tools such as the Verieda example.


CMS Vendor Meme

Posted by: paul

A month or so back one of the CMS vendors (Day Software AG) posted a blog entry in which they invited (as in the game of ‘Tag') a number of other CMS vendors to rate themselves on a 15-item checklist. They had some reactions from the tagged vendors, and other vendors thought it was interesting and responded anyway.

Most bloggers who responded did so in a frank and open manner, which is refreshing. Even the instigators of the checklist didn't pick questions that would yield them a perfect 45 score. However, there was a fairly wide breadth of interpretation in some of the answers and I was left with the impression that the scores weren't really on an interval scale, but were at best ordinal data. Nevertheless, it is fascinating reading for anyone who is looking at Which?CMS.

Compared to the publicly-listed and major-player enterprise software companies on the list of responders, I approached the CogniDox answers with some trepidation. My first conclusion was similar to that from KnowledgeTree and Nuxeo - we are more of a DMS product than a CMS or WCM, so some questions didn't make as much sense as they might have done. There are quite a few DMS features that differentiate products, and these are not featured.

I think what it did do for me was to focus on where we are weakest: Localisation. Because we developed our software initially at a US/UK company we made the mistake of not separating the user interaction dialogs from the rest of the code. Now we struggle to support languages other than English, and usually turn away any RFI or customer request where that will be a requirement. It's an area we have included in our roadmap, but for now we have to stick with the high-tech companies in the UK and USA, unless they are happy with English everywhere.

I was much happier with some of the other answers, such as for example Q9 "We run our entire company website using the latest version of our own WCM products" - there's a neat short description of how we do this in our website library here.

Anyway, I pulled some of the various answers into one combined table, which I'm including here as a useful summary for others.

Some links to the original blogs:

http://dev.day.com/microsling/content/blogs/main/cmsvendormeme.html
http://www.knowledgetree.com/blog/knowledgetree-cms-vendor-meme
http://blogs.nuxeo.com/ebarroca/2009/03/cms-vendor-meme-nuxeos-turn.html
http://www.opentext.com/blogs/ecm_briefs/2009/03/open_text_on_the_cms_vendor_me.html
http://interwovenblog.com/2009/03/22/the-cms-vendor-meme/

To get the latest updates, use this Google link to the meme (9c56d0fcf93175d70e1c9b9d188167cf):

http://blogsearch.google.com/blogsearch?client=news&um=1&hl=en&q=9c56d0fcf93175d70e1c9b9d188167cf

 



Company Blog Tags Document Management Systems