By implementing Microsoft Dynamics, SAP or any other ERP (Enterprise Resource Planning) system, an organization imposes a uniform structure on its data and processes. The uniform structure of data is meant to promote understanding of the entire organization through management reports that can be compared and consolidated. Uniform processes are meant to promote smooth and productive interaction across the entire organization.

These are desirable intentions, but when an organization is large, it includes teams with data and processes that may be optimized for certain environments (market segments, product lifecycle stages, geographies, etc.) By optimized, I mean they have unique processes and organizations of data that work well for them, even though they may be difficult to compare, consolidate, and integrate with the rest of the organization. An enormous challenge of implementing an ERP system is “normalizing” teams across a large organization so they “fit” the uniform structure and can contribute to the benefits of enterprise resource planning. This challenge is tantamount to making teams think and work differently, to participate in the ERP system.

However, each team forms an identity and builds pride around how it thinks and works, precisely when it is different from (and perceived to be better than) how the rest of the organization works. A team may not realize that it is environmental differences that allow or require the differences in data organization and process. Such teams suffer trauma when global processes and structures are imposed on them. In particular, if the global structures are (or are perceived to be) sub-optimal for their environment, teams may actively resist their imposition, or experience failure and loss of productivity.

Collaboration systems like Microsoft Sharepoint, Jive’s ClearSpace, Intel’s SuiteTwo and PBWiki’s product allow individuals and teams to create, organize, and share information. One benefit of such systems is that their use can be initiated by an individual and then grow organically to provide value to an entire team. These systems currently fall short in two ways:

• They ignore processes. A team may want to define workflows that artifacts must pass through before they are considered ready for sharing outside the team. Collaboration systems would benefit from the flexibility to define and enforce such workflows.
• They ignore the value of collaboration between teams. These collaboration systems could actively identify commonalities, across teams, in organization of data and definition of processes. For example, based on the names or contents of tables or columns, a collaboration system could predict that two teams are maintaining separate lists of customers that might be usefully combined or linked. Another example: if the name of the terminal state of one team's workflow matched the name of the initial state of another team's workflow, a collaboration system could predict that the two teams would benefit from closer interaction. Based on such commonalities, the systems could help teams share best practices, support each other's work, and generate reports that can be compared and consolidated, all without losing their individual identity and value. For this to work, collaboration systems would have to expose--and help resolve--discontinuities between the team's organization of data and the larger organization's.

If such capabilities were added to collaboration systems, they might be successfully introduced into an organization and provide the benefits of ERP systems without traumatizing and lowering the productivity of teams. The costs of implementation would also be low if the systems were designed to promote incremental, organic adoption.