Blogging for IT Executive

Recently I was asked to blog for IT Executive. IT Executive is a Dutch magazine and website about IT to help executives in IT decision-making. I thought I'd give it a go and will be starting soon.

Tags van Technorati: ,

Google News Timeline for the Enterprise?

Google Labs recently launched a cool tool: Google News Timeline. Google Search has a comparable feature too if you know what to type in. You can use Google News Timeline to search what has been said about a certain topic, person or brand over time. This is great for companies for instance, but also for research. It helps you get a feeling for the time period the topic was hot, how much was written about the topic at a certain time, etc.

But what I was wondering is, isn't this also very interesting for inside companies as well? We all experienced old ideas coming back to life in companies over time. For some reason that great idea you had didn't really take-off. But now all of a sudden it does.

The strange thing I've seen many times is that this new interest for a topic or idea, doesn't always relate to or build on the research that was done in the past. It looks like a new idea, fresh from the start. But in reality it isn't (-- and hardly ever is). A Google News Timeline in the enterprise could help us look back, find good ideas, relate our seemingly new ideas to older ones, etc. Of course, we'd have to search in the company repositories, which doesn't happen enough. But the presentation of the search results may just trigger employees to start searching and learn from the past.

[Found via the Google Systems Blog. Thanks!]

---

If You Read This and Like It, Tweet This to your Followers:
Google News Timeline for the Enterprise? http://twurl.nl/czrlby

Rules for Archiving Product Data?

old_woman Some time ago I started thinking about how long product data should be archived? I'm not finding clear answers. I've heard people say: "Store it forever". That's the easy way to 'solve' this issue. Other say: "Store it for (about) 20 years." This sounds more realistic. But then I wonder when to start counting. Is this after the data have been created? Or is this after the product has been released to the customer?

Someone else said: "Well, you should keep the product data as long as you have to service the customer's product." Good approach, but how long does the law require me to service a product?

Finally, I found there are differences between types of product data. Product data from medical machines is different from software code of a text editor, for instance. This made me wonder: Are there different archiving rules for different types of product data?

Is there anyone who can help me answer this question? The standards that I found (e.g. ISO 10303) are mostly about ways to store product data in such a way that you can read and edit it over time. Interesting, but not the answer to my question.

---

If You Read This and Like It, Tweet This to your Followers:
Rules for Archiving Product Data? http://twurl.nl/mjkwjx

Information: Lifeblood of Enterprises (2)

Yesterday, I blogged about the statement: Information is the lifeblood of enterprises.29-bloodflow

Today I'd like to use this metaphor to explain why structured and unstructured information should be managed under architecture. Or in an integral way.

I've been thinking and posting about this topic for some time now - it's basically the core of my job. To point to a few posts. Just recently I posted about 'PLM (product lifecycle management) and enterprise 2.0'. And longer ago about managing unstructured and structured information under architecture.

As I've said before: I distinguish between unstructured and structured information in organizations. But they are not distinct. Regrettably this is common practice in most companies. You have people working on Product Lifecycle Management and Enterprise Resource Planning on the one hand. On other you have those that are implementing the intranet, rolling out wiki's and blogs, building document management systems and helping employees use their email effectively. These are two distinct ventures, that seem to have little or no relatedness.

And it's true when you look at the kind of people working in both areas, they are as different as night and day. The first group despises and wants nothing to do with the other. Most knowledge workers hate working in the formal product management and resource planning tools. They're to strict, non-creative, etc. On the other hand the guys and gals that own the formal tools complain that everyone is creating information which is not shared and stored in the 'right' tools.

So, you have two camps. One touts: all should be done in the PLM or ERP system. The others say: throw away the expensive, formal systems, let's just use the 'good' stuff like wiki's, blogs, etc.

Although I relate best to the second group... I don't think one or the other is right. To explain my approach/proposal, let's get back to the thesis in the title of this post: 'Information is Lifeblood of the Enterprise'.

How does blood flow through our body? It 'uses' arteries, veins, smaller and larger blood vessels to transport a.o. oxygen to the right places. Let's say the formal systems, like Product Lifecycle Management and Enterprise Resource Planning tools are the main arteries in the organization. They (should) support the main business processes in the best possible way. But everyone knows these business processes don't summarize the company as a whole. Lot's more stuff is going on in the company. Less formal stuff. People talking to each other, talking to customers, small ideas that are documented and built upon, reports are written to fuse decision making, etc. Oh, yes, these all (should) relate to the main business processes somehow and someday. As the micro and small blood vessels connect to the main arteries. But most of the work starts at the knowledge worker's desk. In his inbox, in his Word document. Typically a very informal process, which seems inferior to the main, formal process. But it's not, relating to blood vessels. If we would cut away the smaller vessels, the whole production and transportation of oxygen will stop!

For this reason, I find it important to define an information management program comprising unstructured and structured information without telling 'unstructured' to become 'structured' or the other way around. Maybe this will mean that wiki's and blogs will become more leading in companies, than they have before. Maybe this will mean that the workflow and change functionality of PLM and ERP tooling will be used to relate wiki pages and blog posts together into a workflow as I proposed commenting on John Tropea's post about Workflow 2.0.

Does this make sense? Does this metaphor help explain the distinction and relatedness between structured and unstructured information? I'd love to hear your thoughts.

---

If You Read This and Like It, Tweet This to your Followers:
Information: Lifeblood of Enterprises (2) http://twurl.nl/6pyk4h

Information: Lifeblood of Enterprises

blood 'Information: Lifeblood of Enterprise' is an interesting thesis. It's an interesting way to look at how the company runs too. I don't think many managers and employees in companies would agree with this thesis though. Those that agree are in information management, IT and communications. And this rings a bell with the 'process people' in organizations as well.

But I do find this to be true, for all or most companies. A consultant once said to me: If this thesis isn't true, then what are all those employees doing behind their computers? What are they working on? Indeed, what they are doing is processing information of different types, amounts and abstractions.

Employees gets emails, with or without links and attachments. These emails contain assignments and tasks. Information from the emails and documents is used to create new information. Then it is shared on a wiki, blog or a collaboration tool. This information is sometimes related to product and/or resource information. Because the document contained requirements for the 2D or 3D design. The design (also information!) is subsequently related to other designs of product parts. These parts need to be ordered somewhere, which is described in resource and logistic information. This is passed on to the supplier by the product data management or resource planning system. Or it's sent to them by email. And we're back to where we started.

Does this make sense? Do you agree with this thesis? And is this the way the company you work for manages information?

In my next post I hope to explain how this metaphor helps us manage all information (structured and unstructured) in the enterprise integrally.

---

If You Read This and Like It, Tweet This to your Followers:
Information: Lifeblood of Enterprises http://is.gd/rbYl

Wireless Printing

As you (may) know I work for a company that makes printers (and copiers and scanners too). I was browsing around on the Wired website. Then I wanted to print (to pdf) one of their articles and I saw this:

hp wireless printing

That's a very interesting and innovative way to advertise!

---

If You Read This and Like It, Tweet This to your Followers:
Wireless Printing http://is.gd/qzJY

Tags van Technorati: ,