24 ( +2 )

A few weekends ago we went crazy. We signed a deal on Friday at 10:00pm, and the customer wanted to be up and running in production 8:00am Monday morning. It's not unusual for someone who works at the Apple Store, I guess, but installing enterprise software isn't like hooking up to iTunes...

So how do you do this? Not so many years ago the response would have been very traditional: round up the usual suspects, put them on planes, meet up sometime Saturday and hope you meet the deadline. Of course, the bulk of the engineering assets (not just code and knowledge, but also infrastructure in which to test configurations and changes) are back at the vendor's home office. And because this is a defense-related firm, there would be the security issues, etc. etc.

But now it is different. In fact, the whole team was different. The customer's people were both on-site and working from their home "data centers." And our people were working from home offices in Austin, Houston and Ithaca, New York - as well as from the office.

Web-based services were brought to bear... most notably WebEx and Google. The customers downloaded our application over an FTP connection, then set up a WebEx and conference bridge, and we watched as the customer went through the entire installation and integration with their technologies (HP/UX, WebSphere, Enterprise MQ, etc.).

The customer began their infrastructure setup on Friday night at 10pm (the minute the contract was finished). By Saturday night, they were finished with that step. The plan was to begin the TeamWorks installation and integrations at 8am Sunday to be ready for production use on Monday at 8am. Roughly 24 hours to integrate to systems we'd not seen before for a production deployment that three weeks earlier we'd heard nothing about (it was a 3 week sales cycle!).

By 10am Monday it was complete. And while it was an unusual effort, it was unusual only because of the 10pm Friday contract signing. If the contract had been signed, say, on a Tuesday and we'd done this during normal business hours the next two days, this event would have gone unnoticed. What is amazing is that this distributed team was able to work together so closely - so collaboratively - and never see one another's face, be literally thousands of miles apart yet sharing the eyes we call WebEx and the brain we call Google, and radically reducing the amount of time it takes to move a new technology into deployment.

Now, there is no doubt there is a structured process going on here. Installation, integration, configuration, testing and deployment have a lot of rigor behind them. But the catalyst for massive changes in behavior are the insertion of these new, collaborative technologies into the structured mix. Marrying collaboration - building in the tools and behaviors of collaboration - with the structure of process into a more-and-more complex world is the challenge of business process management in the 21st century. It's not simply about integration, and it's not simply about rules... it's about having the ability to act in un-modeled ways, and yet still providing the quality control, visibility, and compliance required for a scalable, governable business.

Collaboration in the context of structured process will lead to more process advances in the next 10 years than we've seen so far, since the beginning of automation. The killer BPM application isn't about discovering the process so that it becomes known - it's about allowing unstructured behavior while still maintaining the discovered process context.

Technorati Tags: BPM, Collaboration