Wednesday, November 22, 2006

Google Calendar for Enterprise Mashups?

Enterprise software houses have done a lot to put web based collaboration tools in their software. My feeling is that the business-business (B2B) web collaboration revolution is yet to happen. But it may happen with what is being called the enterprise mashups (something that I understand as meaning data flowing from and into simple and collaborative web applications). This post is a ramble on enterprise mashups with an example based on Google Calendar.

I remember that in Adapt or Die, Claus Heinrich described the major blocking factors for company-company web interaction. The key factor was to put people working together on some numbers. To be able to effectively start the company-company talk he advised against starting with complex software (surprising coming from a high executive of SAP). His advice was to use a spreadsheet in a shared folder, where people from different companies can update the data. Then he expanded to some more software based portal solutions, but for me, the "step one", the shared data somewhere in between two companies is still the vision I retain from the book. In this step one, people would share simple numbers from inventory and production dates from both companies.

For some companies the step one is still a lot of integration. Let’s consider the step zero, something with very low commitment and very low workload, the automatic email to the vendor/customer. For example, company A buys raw materials and wants to know the dates they will receive the goods. If changes happen in the planned dates, they want to know the new dates. So the raw material company B sends an automatic email to the purchase responsible (PR) of company A every time the order confirmed date changes. Taking this as step zero, something that works and is being used worldwide, assuming step one is still hard to reach, what could be step 0.5? Here is an idea.

Google calendar is a web application, very suitable for collaboration and with a programmable API. So, company B could maintain a shared calendar for his customer A, having some interface to automatically maintain the calendar events corresponding to the days the customer would receive the goods. It would still send the mails and the mails can have a direct link to the calendar.

Why this can be a good solution?

There is still very little commitment and workload in the interaction. The PR gets a simple way to access an overview of planned receipts without having to work on the other company software system (this is important because of logins and passwords, learning how to use the tool, etc). And the PR can see several vendors together if they all make their data available for this web calendar system (for sure it would be feasible to offer the data in N possible calendar applications).

At last, and also important, company A can use the API to fetch the data and make it available in their system for further use (for example in the planning). It's quite simple to put and query data in the calendar (but I think currently the Google calendar API does not allow edits or deletes).

The web calendar is interesting. A web spreadsheet having a programmable API could open the door to even more interesting scenarios.

Update: I just saw this link about the integration between the a task management application (Remember the Milk) and Google Calendar. It is a great example of data flow, even simpler than what I was thinking when I wrote this post.

Labels: ,

Tuesday, November 21, 2006

One million and counting

Just a small note (pun) to celebrate OSS having reached 1000000 notes.

Image done with the cool spell with flickr tool.

Labels: ,

Monday, November 13, 2006

Quick links

Ankur Gupta has a new post on transportation management.

People discuss if ABAP is a "relict from the past". I don't think so, when I see someone writing a flickr API for ABAP, I don't see a dead language.

SAP has a new project named Sagres, as Oliver Mainka says: "We started a project at SAP dubbed Sagres (we want to show the world how to make better use of geography, as good old Prince Henry the Navigator did).". Cool! If you guys need some inspiration you can always have some Sagres beer!


Thursday, November 09, 2006

The Zen of PAL

The Zen of Python is a very cool set of design rules collected by Tim Peters (the infamous timbot). Some of the rules are good design rules even outside of Python's universe. I personally borrowed some of these rules for what I consider good PAL (product allocation in global ATP) design.

Simple is better than complex.
Explicit is better than implicit.
Flat is better than nested.

Labels: ,

Wednesday, November 08, 2006

ATP fun

I always suspected that APO ATP was something special. And I don't mean the technology, I mean the people behind the technology. See for example, the first comment in the BOP code:

They are inviting us to some kind of psychedelic party, isn't it?

And check the configuration table of check modes. See the smile? Extreme isn't it? I mean, putting a check mode 666 or 069 would be wild, but putting a :-) is from a different universe.

And we have ABAP code that smiles!

This is the coolest of APO teams (and maybe they also have the best pot in SAPland :-)

Music Playing: Vampyrus Lesbos, Sexadelic Dance Party

Labels: ,