Musings on personal and enterprise technology (of potential interest to professional technoids and others)

Wednesday, January 28, 2009

New Gmail Labs Offline Feature: How will it handle collisions?

Excellent, great to see the Gmail labs have added the offline capability via Google Gears:


Now it will be interesting to see how this mechanism will handle "collisions": e.g.

Suppose while working offline on computer A, I tag a particular gmail message with tag X, and then (before going back online from that computer A), I inadvertently access the same message from computer B [or perhaps SmartPhone B using mobile gmail] while online, and tag it with tag Y:

Will the Gears-based synchronization interactively detect the discrepancy (data "collision") when I go online again from computer A, and offer me the choice to accept either tag X or tag Y?

Or will it silently choose tag X or Y (and if so, which?)

Saturday, January 17, 2009

Does IT really serve *internal* customers? [David Wright via Better Projects]

Thanks to http://www.betterprojects.net/2009/01/serving-your-customers.html for this excellent quote, a new approach to an old question:

"Don't buy into... that IT is a business within a business serving internal customers. There are no internal customers... Everyone within the enterprise is a part of a team that should be working together to satisfy customers and stay in business."

-- as explained by David Wright, in his book "Cascade: Better practices for effective delivery of information systems in a multi project environment"

Wednesday, January 7, 2009

Implementing Business Process Management: Five Not-So-Easy Pieces

A nice common-sense summary of 5 factors, one or more of which "almost always" causes "failure to achieve results after attempting to implement a business process management (BPM) initiative":

Implementing Business Process Management: Five Not-So-Easy Pieces

My favorite (and the factor which I have noticed most often is the true culprit when these types of process improvement initiatives fail), is the last of the 5 items:

"5. Either shortchanging, or entirely skipping, the all-important task of documenting and analyzing the AS-IS process before designing the TO-BE process. I touched upon this in Reason No. 1, but it deserves its own bullet, because most enterprises have never fully documented their current processes. Typically, many things are done on a daily basis simply because that’s the way they’ve always been done. But without capturing and understanding the “why” for each of these, you are flying blind in determining what your future processes should look like. And take due caution regarding your new path: Often, as we fix one problem, we create another. Even if you’re clear on where you want to go, you need to know where you are to determine the best route."