esjewett.com

As currently available, nearly all process platforms are organized for central design of the process and, by extension, require central control of the process. This sort of systems design does a poor job of identifying and enabling process improvement.

The best central design process platforms are spreading out control within a hierarchical system that is designed for central control. Sometimes these systems can succeed, as in the case of the Toyota manufacturing system or Best Buy's ROWE system. But they seem to be working against the grain. Existing platforms work against the management maxim to push decision making as far down the hierarchy as possible because they demand that the final decision be made in a central group, or even more awkwardly, by a consensus of central groups that have grown up their own bases of power.

This is in contrast to a mythical system that allows for organic process growth by facilitating small (or even large) process changes at the periphery, without any involvement from a central decision-making organ. The work of the organization is then to measure the effectiveness of these slightly changed processes in the real world rather than in a mental model or simulation. Decision making becomes a matter of choosing the right measures for these processes, itself a process that can be measured. The measures go all the way up the chain to "what do we want to accomplish?" and "what are the constraints on how we ought to get there?"

At what level should processes be personalized? How far down the chain should the decisions be pushed? Ideally, any person who has a job description be able to control their job process, at least within limits. An important part of this is giving each person the resources to understand and evaluate the impacts of changes to their processes. These impacts might be in productivity, cost, environment, employee/customer satisfaction, etc. Impacts are also on multiple levels: the individual, the department, the group, the division, the company, the industry, etc. The resources for understanding and evaluation will inevitably be focused on a few of these facets but should acknowledge the existence of all of them.

What about the risk? How can we allow people to run off and change the way we do business without vetting the impact before-hand? They might mess something up.

I'm pretty certain that we're already messing up. There's definitely a lot of upside potential in the organizational effectiveness department. The keys here are going to be developing organizational strategies for understanding and evaluation rather than developing securities and controls, as most damage that is done by errant employees appears to be done through a lack of understanding rather than any sort of maliciousness. The effectiveness of most IT and process controls is in their ability to prevent people from making inadvertent mistakes rather than knowingly causing damage. Once this is accepted it becomes clear that establishing control is secondary to establishing understanding.

Organizations may begin to focus the design of their process systems on aligning change and impact, thereby allowing for isolated changes that avoid side-effects across the organization. A sort of functional programming paradigm of process design. This is not the only option, but it fits in with the ongoing theme of decoupling business units. Another option might be to control change to be within certain predetermined guardrails, or to be in accordance with business rules developed in a parallel business rules and controls system, to allow for maximum optimization and flexibility within a more integrated business.

I hesitate to say that this will enable "evolutionary process", as it seems unlikely that we will never achieve the level of iteration and competition that might be necessary for evolutionary process design in the near future. But there appears to be a lot of room for tapping individual and small-group initiative both to improve processes at an organizational level that is not currently seen as cost-effective, and to relieve frustration with centrally developed and decreed processes.

FriendFeed is the hot new thing in social activity aggregation. The basic idea is that it aggregates all of your activity from various online services into one big activity stream. You can find mine here: http://www.friendfeed.com/esjewett.

Doing this type of aggregation means querying the services where content lives on a regular basis for each user. I signed up this blog, so this blog's RSS feed gets pinged on a regular basis. Perhaps too regular a basis.

Those are the stats for a single day. In case anyone didn't notice, I don't post here all that much, so checking ~65 times per day (every 20 minutes or so) might be overdoing it a tad!

Some other feed-catchers do checks at increasing intervals when no new content is found, with a reasonable maximum interval of an hour or so. Such an algorithm, tweaked for FriendFeed's particular case, might save some serious bandwidth. It might also open up bandwidth and processing time to allow it to stay even more ridiculously up to date with frequently updated content.

Twitter is a big ol' international hodgepodge of communities, conversations, and observations to the tune of 700,000+ active users.  Being international, it also tends to be multi-lingual.  Herein lies a problem: I can't understand, say, Arabic.  Or French or Japanese for that matter.  In our brave new world of computerized , automated everything, there's no technical reason these conversations can't be translated on the fly, if only we had a little metadata.

Metadata, in this case, would be data about the language someone is tweeting in.  You see, from a consumer perspective the real problem of automating translation isn't the translation part.  Google and Yahoo! have that pretty well nailed on the level of 140 character tweets that often appear to have been run through a translation program anyway.  The problem is figuring out, automatically, the language of the post and the language it should be translated into.

Enter Twitter nanoformats.  Nanoformats are closely related to microformats.  So closely related that they even live on the Microformats wiki.  Anyway, nanoformats are little pieces of text you can insert into tweets and other things to provide some sort of metadata, like location, tags, or (surprise) language.  The language nanoformat consists of the string "lang:" followed by the iso 639-1 code for whatever language the Tweet is tweeted in.

In order to enable auto-translation, a Twitter user would have to do two things.  First, our user would insert a lang nanoformat in their own bio to indicate the language they normally tweet in.  This bio nanoformat will also be used to figure out the language our user would like to receive other tweets in, so choose wisely.  Second, our user would insert a lang nanoformat in tweets they make that are not in the language their bio indicates.

So, for example, I normally twitter in English, so my profile indicates that with the "lang:en" nanoformat.  But if I tweet something in Spanish, I would add the "lang:es" nanoformat to that tweet.  (Don't worry, I won't subject you to any Spanish tweets, notwithstanding the example below.)

Okay, here's how it works

Now that we've done all that groundwork, the magic can begin.

Warning, the following paragraphs contain forward-looking statements.  No client actually does this stuff yet, though it's conceivable that I am under-informed on that point.

When I fire up my Twitter client and log in, the client checks out my bio and sees that I want my posts in "en", which means "English" in ISO-ese.  We'll call this imaginary client Litter, but we could just as well call it Twhirl, Snitter, Tweetr, or Twitterific.

Now, whenever Litter sees a tweet, it checks the tweet for the lang nanoformat and if it finds one, and it isn't "lang:en" it makes a quick call to http://translate.google.com to translate the tweet, sans nanoformat.  If the client doesn't find a lang nanoformat in the tweet, it should check the bio of the person the tweet belongs to for a lang nanoformat and perform the same call.

So the tweet "Hablo español lang:es" would result in the following call in my Litter client:

http://translate.google.com/translate_t?text=Hablo español&langpair=es|en

Click that and see what comes out.

What happens next involves some screen scraping of dubious legality, but maybe some agreement can be reached.  Anyway, Litter then pulls the result of this query out of the HTML mishmash it receives back.  It provides that translated result as the content of the tweet.

A little discussion goes a long way

There are a lot of reasons this won't work.

First of all, there is a 70 request per hour limit on the Twitter API.  Litter would exhaust that limit in about 5 minutes if it were trying to translate every tweet in the stream I receive.  As a result, I suggest that the translation function be implemented with a manual trigger, at least initially.  The imaginary Litter allows a user to right-click on a tweet and choose "Translate" from the context menu.

It also appears Google's terms of use don't allow this sort of use of the Google Translate service.  Similarly Yahoo! doesn't appear to allow this use of Babelfish.  However, there are a lot of dubious uses of these sorts of tools, so maybe we can come to some sort of agreement.  In the meantime, a working proof on concept would be pretty neat.

Lastly, there should always be some way to easily get at the original tweet within the client, just in case something goes horribly wrong in the translation.  This is technically an opt-in system, since it won't work on a person's tweets if they don't use the nanoformat, but we should still be considerate.

Despite these hurdles I'm certainly looking forward to this type of functionality becoming common, and not just on Twitter.  I know others are as well.  What do you think?  How can we make this happen?

Michael Krigsman blogs at his IT Project Failures in response to a Robert Scoble post asking why enterprise software isn't sexy. Vinnie Mirchandani also responds on his Deal Architect blog. Scoble is asking why enterprise software doesn't get more press, and Krigsman and Mirchandani hold that it doesn't get press because it's doing important things. More likely it doesn't get press because your everyday blog reader doesn't really want to know about the software that processes invoices and manages supply chains, nor should they.

But I think this misses the point. It's not just your person on the street that doesn't care. The people that use this software every day don't care about it. A lot of people use software from SAP, Oracle, and Microsoft but very few of these people view the software as anything other than a necessary evil. I don't think it's unreasonable to attribute this lack of interest on the part of actual users to a lack of sexiness, usability, humanization, etc. on the part of the software.

So back to Scoble's question: Why the lack of sexiness?

I believe it comes down to a tendency to discount aspects of software that encourage use because in the case of enterprise software we can require use. This, of course, despite the fact that you can both require and encourage use.

Because of this mentality, and the resulting software (or vice versa), people don't care about the software they use every day. Not caring results in resignation and a cycle develops under which individual employees don't have and don't expect to have control over their software, their business processes (enshrined in the software), or their workflow (also increasingly in the software). This begins to shape up into a recruiting and retention issue because people who care won't want to work with software that they can't control. But it's also a issue because we leave a huge amount of business and user interaction expertise on the table when designing enterprise software for resigned users.

Now, that's money on the table, but I think the amount of money on the table here is dwarfed by the loss of whole areas of enterprise software. Companies are just starting to try to figure out social software and the jury is still out on this area, though there are some positive signs. How about user-controlled business process modeling, even just for analysis processes? Most people are still using Excel for this.

One area of enterprise software that has been an unmitigated failure is the knowledge management arena. A big part of problem is the fact that people have to be able to integrate the KM software into every aspect of their workflow in order to achieve the necessary level of information transfer into a knowledge management environment. Enterprise software traditionally doesn't enable this type of user control, so failure ensues. Sure, documents show up in KM repositories, but a working knowledge management system isn't really about the documents, it's about ideas and knowledge diffusion.

This is all especially concerning when we have Gartner analyst/VP Jeff Mann holding that "social interaction is the way most value is delivered in the modern work environment" and that "by 2012, the primary role of business networks will be to support social interactions, not routine business transactions." (Yes, I really love this quote.) I assume that Mann includes social knowledge creation in his calculus.

I think we can agree that un-sexy software probably doesn't do a very good job of enabling social interaction. And that's a big problem.

Gartner analyst Jeff Mann has an interesting take on social media in the workplace. He says,

"Social interaction is the way most value is delivered in the modern work environment and predicted that by 2012, the primary role of business networks will be to support social interactions, not routine business transactions."

Most value in the modern work environment is delivered through social interaction and our organizations have no way to measure this value. At best we're using stone-age tools like manual browsing, performance reviews, and email studies to find out who is interacting with whom.

via Accidentally on Purpose and PC World.