ECM made simple – the hunt for

Anyone who has been involve in “Enterprise” Content Management projects will tell you that usually they are nothing but simple. This complexity rises from a number of from education to procedures, politics, skills, adoption, competence, technical chracteristics.. etc

The quick answer to this is to mount a big implementation project. And everybody is happy: the vendor sells licenses, the consulting team has billable months and the customer feels he gets something important since he spends the big bucks on it.

The problem is that this is the default approach from everyone at the table although it’s clear to any sane-minded person that at least half of such projects would be better if tackled with a different approach: give the customer a tool which he would want to use.

Most of the vendors identified this opportunity and addressed it with the “out of the box technical tool” or “platform” approach. These are at best some DIY kits for customer internal IT staff to still try to do a complex projects to address the ever complex business challege. SharePoint executed this quite well at least until it also hit the wall of complex projects/

Because the answer is not a technical tool or a platform.

There is no universal answer either. At least not about ECM 🙂

We need to diversify. We need strong competence for complex projects but equally we need to have a market for simple to use and access business solutions / applications. There are probably very very few who can do both well, I’m looking forward for a disruption in this area.

This requires a culture change for all participants. I can’t count the meetings I’ve been into where the customer pushed to have feature after feature inside the solution while the supplier said mostly “yes” since it would bring him more money. I call this the hunt for more muney and the fear of failure. After all, the supplier needs to eat and the customer to succeed.

From this situation we can’t escape easily. But we do need to.

Cloud is here to help. Is an enabler, not the answer. But it generates the kind of focus which can lead to a new market. The market for simple ECM solutions. Cheap, easy to use and easy to dispose.

Image

Imagine buying a business solution for under 5k. Or paying under 1k/month for the use of your entire business unit.The CRM space is doing it so why can’t we? Basic Office is already like this, are we so much different?
And how do you tackle the complexity I’ve presented at the beginning? You don’t. You just let the customer decide and adapt. Money is the blood of enterprises and if you lower that entry point with a quality product then you just got yourself a new market. This does not exclude the big multi-million projects… it just adds up.It’s tough but it can be done and when can reach with it the impulse buy area for business owners, you struck gold.

But remember: business solutions, with the right equilibrium of features.

See you there!

What should an ECM consultant do

Consulting valueEvery once in a while I find myself in the position of an ECM consultant, brought in by the customer trying to define some Content Management solution or even a big funky ECM platform. And I have also a bunch of colleagues who do this on a regular basis (it’s their job, duh!).

When I picture the consultant stepping in the room I like to see the image of a professional carrying a suitcase, opening it up, putting on the white gloves, calm and imperturbable, client impressed and following with admiration…. you get the picture. So, can we reach this Hollywood dream?

Two weeks ago a senior consultant from one of the top traditional ECM vendor came into a project of mine. The customer specifically asked for the vendor to be involved since it’s about the setup of an ECM platform / vision. Came in, spent 1 week in discussions, generated a PPT and left. That Powerpoint presentation had only one slide actually related to the needs of the customer, a slide which roughly listed some work packages to be done in order to achieve the vision. As much as I would love a magic PPT to solve world hunger, this was not. #epicfail

I’m now doing the same for another project (while trying to salvage the one above also, with my colleagues).

Blank page, customer is anxious…. what should and ECM consultant do?

First: be a consultant. In my mind this translates roughly to this (just some guides, not a full definition.. ok?):

  • know your grounds. You must have deep knowledge about at least 50% of the products and solutions the customer would need. And I mean implementation experience, not just data sheets. Cover the rest of 50% through reading and documenting about it.
  • do your homework. Prepare for the task ahead. Make a plan, write down what do you want to achieve, set up a list of discussion subjects for each meeting, plan for time to digest the meeting afterwords
  • inspire confidence. You are the expert on the field, go to the customer and express confidence in your verbal and non-verbal language
  • be assertive. Nobody likes a consultant who comes and starts bashing things around. You can do that once you establish a trusting relationship with the customer.
  • know why you are here. Have in written form the scope, objectives, mission of the project. Stick with the customer to define them in a measurable and non generic fashion.

Then, be a senior consultant:

  • know the business process area. Don’t go into a telco client and discuss topics from the oil&gas. When you go to a bank, be prepared to talk “bank”. If you can’t… that’s too bad.
  • focus on the added business value, not on the features. This should really be a standard consultant trait… Please be aware that more often than not the ECM platform project will be run by IT. IT is usually a very poor customer when it comes to identifying and following the bussiness value for the company. You will struggle in this case, but please stand your ground!

Ok, but what about “ECM” consultant?

  • make a list of document classes. And for each establish their business owners inside the company.
  • data model. Describe each document class by its attributes. Focus on agreeing on a common set of attributes for all. While it’s very good to have distinct properties for specific class, ending up with hundreds of different schemas is usually very bad. Under 100 would probably be ok for a large enterprise. For a greenfield project, 10 should be fine.
  • make sure the data model has sample values for each and every attribute you list. Each and every one of them
  • user stories. This is more of a generic topic, but I find it especially useful in ECM projects. Focus on the happy path at the beginning, don’t explore (just write down) exceptions
  • map the IT landscape. Also generic, but ECM is very often the centerpoint of integrating data from various sources. Integration, SOA and master metadata management intersect with ECM platforms very well and intuitively from the customer
  • versioning. This can be a pain if not done properly. Start by discussing for each document class when and who creates versions. And how whould they behave.
  • navigation. One hierarchical structure to rule them all? Please don’t. Each business area will want a different perspective on the content. Try to devise a common, minimalistic structure (you need one, don’t leave without it) but be aware that you will need specialized perspectives on the documents almost for all business processes (and usually more than one in the same solution)
  • security. now this is “la piece du resistance”.KISS. If left by himself, the customer would usually end up with a model which is so complex nobody will understand why  somebody has a certain permission on a document. Try to define which security is applied to a document by a combination of 2, maximmum 3 metadata fields. Clearly define which kind of security is to be applied for “search/navigation/reporting” scenarios and which for the functionality available for a document at a certain step. You’ll find the solution quickly after this exercise. Ask “how is this done now?”
  • mockups. Don’t go in an analysis meeting without them. Only the more general meetings in which you define the scope, objectives, mission statement and such things can happen without screen mockups. As soon as you start talking user stories or any feature, always discuss it on a mockup (wireframe, screenshot, live, whatever suits you)
  • search functionality. Search is paramount in an ECM system. It’s not a “given” feature, it needs to be addressed specifically and you must describe who, how and why searches and what kind of information should be displayed by the solution
  • reporting. Don’t close the analysis without having them nailed. I usually like to start with them from the beginning, although it’s not completely intuitive to do this. You could end up revising all your data model from this, so it’s not a topic to leave at the end.

If you do this, you should have 80% covered. The rest is magic.

PCMT – The Perfect Content Management Tool, take two

Continuing the idea of my last post on the topic, let me introduce you to my world of the “ideal” (?) CM tool.

Let’s start with the basics: content. Content is something I want to use for various purposes. Lacking a better description, it’s a file with some additional information attached to it. That’s the “atom”. You can bind some of these together and generate a “bigger” content. Much like atoms attach to each other and form compounds. Or files/cases in our situation.

I’m not going to go deeper that this for the moment. Feel free to rant about it as you wish.

I need a tool to help me work with this content. Let’s call it PCMT.

Since PCMT is something revolutionary, it should show me new ways I can work with the content. Ways I never thought they were possible until today. Isn’t it so? NOT! People or businesses generally don’t like revolutionary things. Think about Galileo presenting his ideas to the general public. Or think about the tons of products which came into the market and had no success until they got reinvented 2 decades later and rocked the world. No, in order to make a perfect tool it needs to be used by today’s people. We are not building the tool for tomorrow.

Ok, that’s settled. The tool will not be revolutionary. Cool, let’s build a filesystem explorer and make it use some metadata and we’re set. NTFS/ext3 anyone? Bleagh, not good enough.

Let’s look at how real people interact with real content today. They take it from wherever it sits and put it in a physical file. Organized by some misterious way in which they hope or know that will help them later solve some task.

Feature 1: must allow the user to “pick up” or “receive” content. Easy, huh? Now… content can be: a file on the filesystem, a file on my USB stick, an email, an attachment, a web page I’m just visiting, a picture in a webpage. A pictore on my phone, a photo in my camera, a voice recording… Easy.

And content must have context. It might be very important if the file I’m picking to use comes from a certain folder on the drive or comes from an email attachment. The tool must capture this.

Capture? Anyone said capture? How about extracting meaningful information from the content, at the point of ingestion? Suddenly this “feature 1” looks interensting enough to spend some significant effort on it.

Feature 2: Help me create files to put content into. Yeah, exactly like getting one of those plastic folders from our lovely assistant, scribbling some acronyms on the cover and throwing the papers in. But electronic. And under the seamless control of the organization policies. Repeat after me: seamless.

Apply business rules. On what? On whatever the user puts there or creates. How? Ask the user what’s all that mumbo-jumbo about and then perform the business validation and raise the necessary actions.

Feature 3: Help the business admins define the rules they want obeyed on the content created by their  employees. Make this easy – aim for trivial – to be technically entered in the system. Something like “all purchasing contracts over 2000 USD must be approved by the corresponding department head before entering the final approval stage”. Or “only secretaries can register incoming documents”.

Then what? Let the employees work towards their business goals while the software makes sure the business rules are observed. Don’t get in the way of real work with software which slows processes to a crawl.

Of course, you can’t define all business rules in software. Much like you cannot build a software to interpret the law and give the verdict. You still need a judge for that.

Feature 4: Provide visibility on the whole data. Turn data into information by presenting it into context to the users. Detect anomalies…. Such as: “user X, although it has the same business role as Y, creates 10 times less documents of type T in a month… I’m going to inform the department lead about this and let him/her judge what to do if it”

Enable the user drill down into the information. Search, navigate, faceted something, metadata driven navigation, pivots, reports… whatever you call it.  Link together the pieces, show the people who interacted with a document, and show me what other documents did they access/change in the process… show me the most popular documents used by my coworkers, show me the fact that a new document entered the system related to a search I did last week.

Feature 5: Help IT. Please don’t make it a pain to monitor and keep alive. Once its installed, it must “just work”. Unattended. Don’t complicate the architecture with multiple modules stiched together with duct tape. Or worse, orchestrated as if they were a cards castle. All the IT should need to do is to monitor CPU/Disk/memory usage and act on them. And the error log. The system must have one place for all logs. Core, addons, applications… whatever. Not to mention a common format.

IT is your friend. You want them to be your friend. Provide them with statistics and notifications on important IT related events. Enable them to define quotas for users or groups. Help them perform chargeback calculations. Report the licensing usage.

Too much for you? Go play with your toys then, father has some things to do.

BANG!

Reality check:

Check-out / check-in! …. WTF !?! Who the f.ck understands that? I edited a document and now no one can see the changes I’ve made and they can’t edit the document either, although it’s secured with a key besides it…

Some ACS server was not available for UCF to … what?

New document? What object type you want to create?…. Me? Dunno, I just have this contract on my desk.

What should I do with this task? Says I can “Forward” or “Delegate”. Hmm…..

I want this invoice to be attached to the PO…. If I put it in this folder is enough? Yeah.. cool.. look… it sits there and does nothing, because I need to call a developer to build the business logic so that it links.

Have you checked the renditions? Your PDF should pop up there any minute now. Or in some 1-2 hours… depends.

Do you want versions with that? Remember that the one labeled with _TNERRUC is the one you need.

…….

No, I don’t like this world. Let’s fix it!

PCMT – The Perfect Content Management Tool, take one

In my last post I cried out about the need to have Content Management as a tool. This does not mean that “solutions” are not good or useful. Of course they are, but they can support (well) only a fraction of our CM needs. For the rest, we need a tool.

Note that I’m not talking about “Content Management” as in “Web(site) Content Management”. I’m talking about the CM as in the management of content, when content is defined as a set of data, usually not just a row in a table. Also, this is not a post about the definition of CM… there’s enough of that already going on…

The journey begins in 2004 when I was discussing with a customer and we were doing the requirements analysis for a contract management solution. On my question about how does he see the best software solution to its needs, he replied:

“I would like to have one big button on the screen. And when I push it, it should do whatever I want it to do. That’s about it, I’ll be satisfied with that.”

Perfect Content Management Tool. (obviously, you can replace CM with anything and will still be valid)

Nirvana.

After a few laughs we resumed the more down to earth talk and ended up with a decent set of requirements. But the idea of the “big button” still lingers on. With me and also with my – now old – customer.

Can it be done? Sure!

Now? Dunno. But I will try.

Let’s analyze, split and address the challenge ahead.

There should be “a button”. Ideally “the only button”, but we could probably negotiate on that. A button is something simple to understand by the user, it’s accustomed to its behavior. We should not necessarily stick to an actual GUI button, but instead understand the idea of offering to the user something very much close to the usual things it interacts with each day. For example it can also be a “link”. But it needs to be big, aka “visible enough”. Menus probably don’t work.. as they are a little more complicated.

The button should do “what I want”. I  specifically remember the customer saying “what I want“. Not “need” or “should be done”. I’m not sure right now if it’s easier to to a button which does what’s needed vs. one which does what’s wanted. Anyway, one which does what “should be done” is definitely the easiest of all magic buttons.

How do we make such a button? Well, the button should “hear” the context in which it stands, should know the context in which his user is and must know what resources he can access and which are the processing paths it can follow. Probably also a lot of other things, but these are the ones I feel are important right now.

Hear the context in which it stands

The button is somewhere. Because it exists.

For example, it should know its location on the screen (c’mon, this is easy)… but not for presenting itself to the user. It needs to know this because the position might have a meaning. If it’s on the top right corner then maybe it will do something completely different than if it’s on the bottom. If the button is on a laptop screen it might perform other things than if its on an iPhone. I know it sounds simple, but remember we’re talking about “one” button. Only one, not several ones.

Ok, but you said “hear”. Yes, the button must be able to hear (not receive as in “destination”) the messages sent by neighboring other “things”. This is happening right now at a primitive level with GUI buttons on presentation software. But I’m not talking about that. The “button” is just a metaphor at this moment of the whole tool/software thingie. The messages are in my view, not technical ones.. but more linked to the data the user interacts with and to its meaning.

In order to hear, the button must have the receptors for this. Webservice listeners, message queue monitors, event handlers, psychic serial bus.. you name it.

In order to understand what it hears, the button must speak the language of the message. This is where standards or public formats come into play. Both are good, I’m not advocating one over the other, let the real life decide. The more standards / public formats will the button speak, the better the button.

Know the context in which his user is

Is my user in an airport, is he at his desk, is she in a meeting, is there some public wireless within reach? This sort of data must be available to the button and it should know them. By knowing this, it has more data to process and be more prepared when the user clicks it.

and so on…

What’s this got to do with Content Management?

Where is my ECM?

Nowhere near, I’m afraid.

But I bet we can get it closer. Not in one swoop, for sure. But would if be that hard to make a button called “Get” which will adapt to all of the above and try to surface my accessible content from wherever, and help me get to the one I want in some 2-3 clicks through a faceted navigation?

Since the button is sensitive to it’s context, we can move it around on our digital workspace and activate it when we reach the are we’re focusing on. Or when it “glows” (probably because it just detected that he can tell me something “new” about the context).

Does it sound Science Fiction? Not to me. Just came to mind: “instant search” anyone? Things are moving, get on with it.

Just a tool

“…abolish the ECM, CRM, BPM, email and the new E20 silos” by Max when discussing this.

That’s  what triggered this post.

In the last few days I was day dreaming about what’s to be done next. What stuff should we create to help our customers (to make some more money, actually). So I thought why our customers don’t use ECM and BPM and Collaboration as much as we would want them to. Because that’s why they don’t buy it – they don’t use it so much. Sure, there are some solutions which are actually skyrocketing in usage… but those are just about 20% of the pack in my world.

What am I using each day? Outlook, Word, PowerPoint, SharePoint, Visio. Webex and Connect sometimes. WordPress ocasionally. Chrome and Internet Explorer, a file manager. No “solution”.

My colleagues? + Eclipse, Visual Studio, small applications

My other colleagues? Very few some use the ERP/Financial software. Some CRM, but just at minimal. An incident tracking system…. A contract management solution (cool!:)) .. a workflow solution for holiday requests.. And that’s pretty much it.

So.. only 2 solutions on ECM and BPM. The rest is quite ok handled by SharePoint as a tool.

Bingo! Evrika!

“As a tool”

Just a tool, damn it! This is what I need. I need a tool to help me. To know what I’m trying to do and make it easier. Like document editors, like email clients, like sharepoint. Sure, you can write code in MS Word/SharePoint/Lotus/… but why bother? It’s good enough for the 80% of us as it is.

Let’s build a tool!

People need a tool for case management, a tool for collaboration or a tool for both. A tool we can use as we please, when we want and how we want it.

The tool should know about “the cloud”. Or be the cloud, or whatever does the trick. The cloud is a resource the tool can help me use it.

A tool is something simple to understand. Although it might also be complex, but simple on the surface. It can be a swiss army thingie. Or just a plain screwdriver. That’s why (maybe) iPhone/Pad apps have so much success. They are tools. Convenient to use, straight to the point, available, purchaseable (is this a word?).

Give me the tool! Let’s make the tool! I’ll go make the tool!