Part 2, Collaboration Tactical Verticals - expanded! (Statement 10)
June 17, 2008
Highly optimized teams perform at high levels - their productivity exceeds the sum of the parts. Moreover, each member contributes at a higher level and becomes more productive. Of course they also feel more committed and take pride and ownership of accomplishments. If done right, the team is the vehicle to bring game-changing, record-breaking innovations to market!
It’s no wonder that the investment in teams is the single best investment!
Gartner predicts that “by 2008, 50% of individual performance will be determined by the individual’s participation in projects and other collaborative work. This will cause an accelerated demand for collaboration, informal project coordination, social networking, expertise location and social process support technologies.”
It is now a business minimum to monitor activities on an almost 24/7 basis - just watch your spouse on vacation try to put away that blackberry! With travel costs soaring (gas prices), we are now relying more on mobile technology, web conferencing and high-resolution videoconferencing - especially as our virtual teams become the norm, expanding across time zones, and national, linguistic and enterprise boundaries.
The needs are real, very real. And if not met properly, shadow IT steps in to fill that need. The result…email grows out of control to morph into some kind of collaborative document repository, and source for best practices and even stretching to perform workflow. There are also non-coordinated initiatives in play that lead to multiple standards and duplication of costs and efforts. At some point, these will need to be reconciled. It is not different then the company that allows master data management to consist of enterprise level spreadsheets to hold data in a persistent manner. Yikes!
Lets start by stating the need that your success will depend upon the appropriate standardization and scoping of the collaboration stack. I view it as a 2 dimensional thought. The first dimension is strategic - it’s the enterprise level (horizontal) of collaboration. This is the level that everyone (knowledge workers, that is) in the organization is aware of and has come to depend upon. This builds upon the intranet concept, bringing to the organization additional corporate-wide tools. This is a good step in changing the corporate’s culture - but that is another blog yet to be written. The second dimension is the title of this blog “tactical verticals”. This is the ability to scale collaboration services ‘when the time is right’. Better said, when initiatives exhibit different configuration of characteristics, then there is a corresponding configuration of collaboration services. Hopefully, these are kept to a few in number and truly driven by need.
It’s always good to start at the foundation. So, lets group collaboration a couple of ways and list out our potential services. There are web-based and non-web based technologies”
Web-based collaborative technologies: Email, Web Conferencing, Team Sites, Document Versioning, RSS Reader, Forums, Chat, IM, Surveys, Shared Calendaring, Social Software, Knowledge Mgt. Systems, Blogs, Wikis
Non-web based collaborative technologies: Telephony, Faxing, Voice Mail, Video Conferencing, Workflow, Project Mgt. Systems, Code Control
But, lets group them by functional capabilities:
Electronic Communications
PC Based eMail
Mobile eMail
Wikis
Community Sites
Team Sites
Document Versioning
Blogs
RSS Reader
Electronic Conferencing
Forums (message boards, discussion groups)
Online Chat
Instant Messaging
Internal Survey Tools
Web Conferencing
Collaboration Management
Electronic Calendars
Workflow Systems
Knowledge Management
Social Software Systems
What are your next steps…? There are many angles to consider, but for this blog (tactical verticals), I would suggest:
* Take inventory of your current toolsets
* Determine who owns ‘collaboration’
* Decide upon a horizontal enterprise-wide standard
* Develop tactical vertical attributes (when do you need IM, voting, work flow, wikis, etc…)
* Configure a collaboration stack for each scenario
* Perform a gap analysis (what do you need that you don’t have)
* Determine standards (products/technologies/best practices) for each
Take the next steps…look at:
- Value
- ROI
- Current Culture
- Transitioning
- Marketing
- Etc…
Having tactical verticals ensures that you can scale your collaboration stack when you need to - the goal here is to match the team’s need with the appropriate technology. Simply allowing everyone access to everything may introduce the wrong controls and lead to chaos and confusion. You have one shot at this - you can’t un-ring the bell! Once these tools are embedded in people, processes and technology, they are hard (if not impossible) to remove. The key to consider is to keep your options few, so that you don’t end up with a dozen different configurations to manage. Click here for my 13 points regarding collaboration
Good Luck!
~ Scott Felten
Part 2, Collaboration Definition! Expanded. (Statement 1)
June 17, 2008
“Consensus is the lack of leadership!” - Margaret Thatcher. I am in total agreement with that statement. As a matter of fact, I absolutely love it and have lived by it for many years. Question: Is collaboration simply a way to gain consensus? If so, then is it valid to say that “Collaboration is the lack of leadership”? I say, yes…and no!
Definition “People working together on creative, non-trivial issues that requires deep thinking and an exchange of ideas in an iterative and cumulative manner by domain experts.”
I will try to state this as simply as possible and demonstrate why “Collaboration may or may not be the absence of leadership”.
But first we need to understand teams. So, let’s look at team dynamics (attributes of a team). If you have read any of Jon Katzenbach’s books (The Wisdom of Teams and Peak Performance, as well as Real Change Leaders and Teams at the Top), you will walk away with a better understanding about the various aspects of teams.
There are 3 dimensions to any team.
• The Challenge – Business problem to be solved
• Work Style – Type of work, level of communication
• Leadership Approach – Applying the right leadership style
The type of business problem dictates the work style and leadership approach for the team.
Coordination-oriented Teams.
Is the business problem familiar to the organization, is it based on a known process and is it time sensitive? This dictates a team of highly specialized experts in their domains, working individually on their part of the solution and time is the driving factor. Coordination is key for this type of team. It is lead by a leader that coordinates individual contributions. In this case, the collaboration level is not as deep. It may be a common repository for terms and reference documents as well as the place where final deliverables are held and project plans are maintained. Often times the implementation of this level of collaboration is tactical – the company sets up a base set of collaboration features for ‘any team’ – its just the standard corporate collaboration configuration.
In the case, collaboration is simply a minimum level of service offered by the organization - a strategy set awhile ago. Here, consensus may in fact be the lack of leadership; as the type of business problem and work style demands a high degree of individual leadership. Here the leader needs to be the main broker of communication; keeping track of the project’s schedule and deliverables. Here the leader would make decisions (of course a good leader always seeks advice). I would agree that on this end of the spectrum, collaboration may be the lack of leadership. In this case, poor leaders may fall in to the trap of allowing the group to lead.
Collaboration-oriented Teams.
However, if the business problem you are trying to solve is unfamiliar to the organization, it is likely that your team will need to invent new processes. In this case, while time is certainly a factor, the best solution takes priority (implementing a poor solution in this case is disastrous). For these team attributes, collaboration is key. This type of team often shares in the work and often rotates leadership responsibility as domain experts lead discussions. Here the team is mission lead. All team members work collectively and share information at a high velocity. In this case, the collaboration level is deep. It may have custom designed work flows and voting/survey tools. Each member is available via online chat. Document management with versioning and edition features are enabled. There is a high velocity of meetings handled by web conferencing. Also the use of wikis and team electronic calendars are priority 1 – so that the mission continues!
In this scenario, collaboration is tactical – it is deployed because the business challenge demands a high velocity of collective work – a high degree of communication and thought sharing. In this case, the role of the leader rotates as people. Here collaboration is not simply gaining consensus, rather here collaboration is leadership!
I have painted both ends of the spectrum. The truth is always in the middle. Keep in mind that during the different lifecycles of a project, your team dynamics will ebb and flow from individual coordination to team collaboration. The trick is to choose a level of collaboration that will scale to your need! More to follow! Click here for my 13 points regarding collaboration.
Happy Collaborating!
~ Scott Felten
Describe Your Day
June 12, 2008
When analyzing information, one tends to always limit one’s view to a certain time frame. Whether by a specific date or over a span of days, data is often meaningless unless you can put a box around it. Obviously other filters come into the mix (product, geography, corporation, etc.), but the common denominator is most often time.
Having been a part of a number of data warehouse projects, the “Date” dimension is a common debate session and is often re-invented from project to project. Why? When it comes to high pressure deadlines and deliverables, why can’t we have a cookie cutter Date dimension that can be tailored and tweaked as necessary to meet your project needs? Well, we can, but first we must decide on what the cookie cutter attributes would be for the dimension.
Take a few moments and see how many different ways you can describe a day. Tick, Tick, Tick. How many did you come up with….5, 10, 20? I came up with 84 (including a few found courtesy of internet searches) and then stopped. Some examples….actual date (duh Dave!), Month name, Week starting date, Quarter number, Weekend indicator, Fiscal Year, Last day of Month indicator, Day number of the year, etc. Obviously some of these attributes can be readily calculated using database SQL functions, however when dealing with large data volumes, reading directly from a table vs. computing on the fly is preferable from a performance standpoint. You also don’t want to burden an end-user to have to understand how to strip out the day portion of a field formatted in MM/DD/YYYY.
The Date Dimension is one of the few dimensions in the data warehouse that you can pre-populate once and forget about it. With 365 days per year you can populate your table with 50 years of data for the low low cost of 18,250 records (give or take a leap year or two)…peanuts in DW speak. Now give your user 84 different ways to describe a day. Pretty powerful analytics to browse through. How many sales are closed on the last day of the month? What is the average attendance of a baseball game on a weekend compared to a weekday or a holiday? How many weeks has your system been operational since its inception?
One common debate topic on the Date dimension is whether or not one should use intelligent or non-intelligent surrogate keys. Surrogate keys provide a means to relate a metric/fact (i.e. Sales revenue) to a dimension (i.e. Date, Product, Sales Rep) that describes that metric/fact. Common practice is to use non-intelligent surrogate keys in order to not tie the data warehouse to business codes that could conceivably change over time. An example of a non-intelligent key would simply be a numeric field that automatically increments each time a new dimension record is added to the table. Meaningless to you and me, but insures that the connection between the metric/fact and attribute will never be broken. One could argue that the Date dimension is not susceptible to changing over time. For instance, if we took today’s date and converted it to an intelligent key of 20080612, this would never change over time. I could then write queries directly against my business metrics and limit them based on my interpretation of a date without having to perform a database join to the Date dimension resulting in a faster query. Something to consider though is a common practice of placing records within a dimension to associate metrics that have an “invalid” or perhaps “not applicable” dates associated with the transaction. If my Date dimension has a intelligent numeric surrogate key, that I have to come up with some bogus key (i.e. perhaps 9999999) to hold an “invalid” value or maybe -1 to mean “not applicable”. Now it becomes difficult to interpret these values on the fly. With a non-intelligent key, you are able to make these “non-dates” easily identifiable by simply including another attribute such as Type of Date.
What about Time of Day? Time is a bit different. How many different ways can you describe 1:00? AM/PM, Work shift (maybe). Normally time attributes are linked within the context of a day. For this reason you normally don’t see a separate Time dimension and in fact, it is becoming more acceptable to just include the date/time combination as another kind of metric on your transaction while still allowing for the additional 84 ways to describe the day.
So while we are often pressed to work faster and better everyday, it makes sense to take some time out to build your toolbox of re-usable components. The Date dimension is a good place to start. Create the dimension in a data modeling tool such as Erwin. You can then create various data definition language (DDL) scripts to a variety of database platforms (Oracle, Microsoft, etc.). Build a one-time CSV file to populate the table and you can even eliminate the need to ETL the data into the table by creating Insert commands with the scripts. Might not be the fastest way to actually insert the data into the database, but with a one-time operation that will occur on your time, why bother with something more elaborate?
Anyone tell me if 5/20/2041 is a US holiday without checking?
Dave
13 Statements about Collaboration - each less than 143 characters!
June 11, 2008
I was thinking about two things today…Collaboration and Microblogging. So, I mashed them up a bit here. I outlined in 13 parts, my thoughts about collaboration. I pasted them here in a microblogish format and they form an outline. Over the next couple of weeks, I will post a blog dedicated to each “Part” - for those of you interested in one person’s experiences. Feel free to comment me up! Here goes…
Statement 1, “Collaboration Definition!”, “People working together on creative, non-trivial issues that requires deep thinking and an exchange of ideas in an iterative and cumulative manner by domain experts. Click here for part 2 of “Collaboration Definition!”
Statement 2, “It’s not about technology!”, Technology is simply a dimension around an implementation method-they come and go. A great idea is to slice your bread - who cares about the toaster, until you want toast! Click here for part 2 of “It’s not about technology!”
Statement 3, “Collaboration Success!”, Real Success - The art of understanding your corporate culture and how to transition them to a focused sprint of collaboration to solve the problem extracting real value.
Statement 4, “Collaboration Transition!”, Transition your company’s conduct, habits, culture and management. Encourage the deeper level of communication. First expose the real business goals and objectives!
Statement 5, “Collaboration Accountability!”, Establish a clear level of accountability - one person who is tasked to demonstrate the value that collaboration brings. So, IT and Business alignment is mandatory!
Statement 6, “Collaboration Value Alignment!”, Make sure that you revisit with the sponsor(s) often to ensure that the value they expect is in fact the value you are working towards. Business changes, adapt your plan! Click here for part 2 of “Collaboration Value Alignment!”
Statement 7, “Collaboration Attributes!”, Choose attributes; re or pro action, rich features or limited set, centralized control versus distributed, technology controlled behavior or community managed.
Statement 8, “Collaboration Scope!”, Apply collaboration to the enterprise, LOB, business unit, workgroup, or even a business process. Suggestion: Horizontal Strategy + Tactical Verticals.
Statement 9, “Collaboration Horizontal Strategy!”, Determine an enterprise level of depth that addresses higher level issues across the organization. General company dialogs at this level promote a culture change.
Statement 10, “Collaboration Tactical Verticals!”, Analyze your company and look for deep level collaboration needs. They usually center around master data items, governance groups, departments, teams or initiatives. Click here for part 2 of “Collaboration Tactical Verticals!”
Statement 11, “Collaboration Business Processes!”, Setting up collaboration at the business process level provides maximum value because its focused on a real need while cutting across the enterprise to involve others.
Statement 12, “Collaboration Business Processes - warning!”, Make sure to determine the right-level collaboration strategy before actually embedding it into the business process, least they become dependent upon one another.
Statement 13, “Collaboration Business Processes - Challenges!”, Different locations and time zones, clear exception handling, management coordination of shared processes and working across political boundaries.
Cheers!
~Scott Felten
How I Reduced My Gasoline Expenses by 40%
June 10, 2008
My daily commute averages just under an hour assuming I leave home by 5:45 in the morning and make my return trip before 4:00pm. Now, when I accepted my current position at LUCRUM as Marketing Manager gas was about $3.00 per gallon. Roughly 100 days later, it is hovering at just above $4.00 per gallon, and showing no signs of plateauing. That represents a substantial increase, and one which costs me quite a bit of real money. I am fortunate to own a very fuel efficient vehicle, but still need to fill up multiple times in a traditional 5 day work week. After much thought and careful consideration I have found a way to reduce my gasoline expenses by 40% a month. Let me explain how.
When I am not listening to books on cd from the library during my daily commute, I tend to listen a fair amount of talk and news on the radio. I am constantly barraged with “what to do about soaring gas prices?” Generally the answer given is something like, fewer SUV’s and more fuel efficient cars, use bio-fuels, tax the oil companies, switch to alternative fuels, move to the city and walk to work, drill for more oil, etc… I hear Senators, Congressmen, Presidential Candidates, The President, American Consumers, Business Owners, and Foreign Dignitaries all expound on how to solve this pressing issue. From liquid coal to switchgrass, ANWAR to Ethanol, hydrogen to methane to propane, there are a multitude of solutions, but none that is viable today. At least that is what you think….
Now all of these ideas have merit. While I agree with some more than others, you can make rational arguments that any of these solutions could yield marginal decreases in the price of fuel. But marginal decreases are not what we need. You see, while these ideas are all sound, they treat the symptoms of the problem. We need something to strike at the root. The game itself must be changed. We spend an inordinate amount of time placing the blame on “big oil” when we are reluctant to change our behavior in the face of price increases. Simple economic theory will tell you that these companies are going to charge as much as they can until the behavior of the marketplace forces them to change. Consumers have given these companies no form of retribution for raising prices. We continue to fill up, drive to the office, and complain about high prices, but we do nothing.
I am here to tell you that there is a simple way to reduce your personal dependence on foreign oil at the micro level. At the same time, this way could improve the environment, enrich our personal lives, reduce company expenditures and increase workforce productivity exponentially. The real alternative fuel is utilizing collaboration technology and the internet to get more work done, more efficiently, and at a much lower cost.
Collaboration Technology has allowed me to work from home on average 2 days per week. Thus, by this simple change in behavior I have reduced my consumption of gasoline by roughly 40%. I would like to increase that to 4 days a week, but baby steps are required for both me and my employer. Thus, I am sticking with 2 as the goal for now. Now, I ask you, what the net effect would be if consumers across the country were to embrace this trend? Well there are a few simple conclusions that come to mind.
First, by reducing the demand for gasoline, the overall supply would naturally increase. Now, the math does not work out exactly the same on a large scale as some people just can’t work remotely. Nurses, Doctors, Truck Drivers, UPS, etc… So the aggregate reduction in demand would admittedly be less than 40%. Still, if those who could work remotely chose to do so 2 days per week, the effect would be very noticeable. Include in this number those who are in sales, logging countless miles of windshield time to meet with clients in person and the impact increase more. Collaboration technology, delivered via the internet, empowers people to effectively “be in the same workspace” without ever leaving home. Let’s see switchgrass do that. Now this has a direct effect on gas prices in that Less Demand = More Supply = More Pressure to Lower Prices!
Now assuming that the distribution of remote office days was spread evenly across the work week, there would be a noticeable improvement in traffic patterns. Highways would be less congested - leading to safer driving, less gridlock, and as a result increased fuel efficiency. (Cleaner Air would be an added benefit, but that is another post.) Greater fuel efficiency would translate into reduced demand for gasoline. Again, Less Demand = More Supply = More Pressure to Lower Prices.
I don’t know about you, but I believe that if this trend were noticed, oil companies would act to stop it before it became a cultural norm by… lowering prices. Again the consumer benefits. Should this trend catch on and expand to 3 or 4 days a week, a virtuous cycle would develop, with oil companies again needing to reduce prices to entice you back into your car. Now the consumer would have a choice again, and oil would develop more of an elastic demand pattern. In short there would be real and measurable consequences to increasing prices - consequences which today don’t exist.
Finally in the benefits column is the fact that by working remotely 2 days a week, I recapture at least 4 hours of time that can be spent more productively. Exercise, family time, reading, working, and other activities easily fill the void created by eliminating my commute. Time is truly our most precious commodity, not oil. Giving me back 4 hours of productive time outweighs any economic benefits offered up in the first two reasons. More time = happier worker = lower turnover = more profits for company
So, in summary we would have fewer cars on the road, filling up less frequently, more empowered consumers, a better environment, and a more efficient workforce. Personally, by adopting this work model, I have more time, more money, and I am a better employee. It is just that simple.
I truly believe that the technology world needs to speak out about the concept of Collaboration as the Alternative Fuel of the Future. We are operating modern businesses on a factory model created to optimize the businesses of the industrial revolution. This system required people to work as machines, and the machines to be present to add value. This paradigm is no longer relevant for many of us, yet we continue on with business as usual. It is time to begin to use the collaborative tools of Enterprise 2.0 to solve problems in new and innovative ways. IT should be leading the charge in reducing the dependence on foreign oil, and allow us to get beyond simply blogging about how we hate high gas prices.
More to come on this concept in future posts. I would love to hear your thoughts on how collaboration can change the world. Please share your comments.
Taxonomy: It sits in the critical path of …
June 9, 2008
Where is the excitement around this issue?
It seems that “Taxonomy” was my word for the week. This is my third post about it within 7 days. It’s not that I am in love with the word, rather, it’s just pretty darn important! With any big initiative, the first thing we look to is a solid foundation for communication. Think about it, we usually address taxonomy anywhere from casual discussions to formal governance groups for many initiatives – dare I say any initiative that strives to bring real change to an organization begins with taxonomy (either consciously or subconsciously). Thinking it through, here are some of my top-of-mind game changers that require a solid taxonomy:
• Master data management. By definition this is really an enterprise taxonomy that is the official reference data for an organization.
• Metadata management. Tagging data with information is best performed only after a taxonomy is well-established. Else, with-what-shall-I-tag-it plagues the process.
• Business Intelligence. Without a proper taxonomy, how do we bring together people from diverse business perspectives together to understand data from a central and enterprise viewpoint?
• Data Management. Well, of course we can’t properly manage data without knowing where things are in a hierarchy or what context the data should exist in.
• Data Quality. Here we are really measuring data against the taxonomy; whether implicit or explicit.
• Governance. Strategic decisions are made for specific purposes and they need to rely and depend upon a socialized and accepted taxonomy.
• Data Stewardship. This is the process of holding someone accountable for making tactical decisions to implement strategic direction.
• BPM. When we look to manage business processes, they depend upon real information. So, having a taxonomy to base these data points is crucial.
• SOA. Reusing software components and exposing them at the enterprise level demands a highly accepted understanding of the organizations data. Sure, this view is exposed as a group of web services that are published in a repository that is self aware – but without a canonical data model as your underlying foundation, consistency is not reached. A canonical data model is highly correlated to a mature taxonomy.
• Strategy, Solutions and Architecture. It’s near impossible to calibrate these three without a friction free flow of communication. Let’s not talk about what should’a, could’a and would’a – but let’s focus on the business problem at hand. Having a living taxonomy that is socialized, accepted and part of our DNA is key to gaining quick momentum as we put distance between us and our competition.
These are just some quickies that I bubbled up. What other initiatives need a solid taxonomy? Thinking about taxonomy, when you look to bring real change to an organization, what happens? From my experience, there are two choices:
1. Address taxonomy early and often. Realize that there are some things that are so important that we need to establish, socialize and enforce them.
-OR-
2. Jump to build a solution. Then realizing there are terms misaligned, misused and duplicated, go back and either fix the data models (and all subsequent diagrams and code – this rarely gets done) or create a lot of code to hide these issues. When we do this, we establish a short term brittle foundation that breaks when the next change comes or we end up with a bunch of custom spaghetti that tries to tie things together but really ends with just a lot of confusion.
Bottom line
• Embrace taxonomy within your natural collaboration style. When something is unclear, pause, ask, record, check for understanding, agree on the outcome and move forward. It’s not a development phase, don’t sell it to senior management. No one cares about it. It’s an expected minimum of doing business. Add it to your culture’s DNA.
• Don’t underestimate the issues when terms are not aligned. It wrecks havoc to your foundational infrastructure and the costs (both hard and soft) can be big. Know it is there and plan for it.
• Scope your risk. If you are working within a group or team, the risk is small. Plan for it and cross it off your list as you develop it. However, if you are aligning silos or working across divisions or bringing others into alignment, or working cross-culturally, or introducing new teams, these issues can be big. Again, plan for it – put someone in charge of its care and feeding.
• Use it as a way to create excitement and ownership. Once you work together, it is always good to look for accomplishments to celebrate. Depending upon your scope, it can also be a way to generate a new level of buy-in. Manage the group right and they walk away with the justified feeling that they had part in it – that they created it and it reflects their slice of the business. Trust me here – then they will socialize it and ensure that its followed in their domain!
Now that is exciting stuff!
~ Scott Felten
Enterprise 2.0 and Governance
June 8, 2008
Prof. Andrew McAfee (see my previous post) in a blog post in Nov 2006 asked his readers to consider this: Imagine two competitors, one of which has the guiding principle “keep security risks and discoverability to a minimum,” the other of which is guided by the rule “make it as easy as possible for people to collaborate and access each others’ expertise.” Both put in technology infrastructures appropriate for their guiding principles. Take all IT, legal, and leak-related costs into account. Which of these two comes out ahead over time?
My guess would be the latter.
So, what is Governance?
In simple terms I’d say that Governance is the set of policies, procedures and structures you define and establish in an organization to guide and direct the use of technology to achieve organizational goals. So it is about both IT and the business.
Many people think governance is about control and limiting the power of the user. On the contrary I think that good governance actually enables better collaboration - the more clearly the terms of use and the collaboration structures and mechanisms are defined, the easier it becomes to navigate the world of unstructured content. To me, governance is like the banks of a river - without the banks the river waters could cause enormous destruction and would spread out and be wasted. The banks provide direction and enable the river waters to be channeled and to achieve useful purposes.
In the Enterprise 2.0 context, one finds that companies are concerned when it comes to allowing the use of such technologies across the firewall. The typical concerns are around monitoring the content posted in blogs and wikis, fears over potential lawsuits emanating from the publication of information that is slanderous in nature or hate-oriented or which can be interpreted as being harassing or discriminatory in any shape or form. There is also concern around the potential for trade secrets, new product information, R&D information and other such inside information getting out. At the client I am at currently, there is tremendous concern over the possibility of allowing for collaboration between internal employees and any external entities.
I wonder if the very same concerns existed when email was first introduced or way back when the telephone was first made available in a business setting.
Most companies tend to have an information security policy and that seems to have generally sufficed to handle these concerns around email and phone calls. In a similar fashion, I think it’d be useful to extend that information security policy to cover Enterprise 2.0 technologies such as blogs, wikis, RSS, podcasts, social networking, etc. It’d also be useful to highlight and publicize these policies so that employees are aware that instant messages or blog or wiki posts or comments on a discussion thread are to be treated as public communication. Also, one needs to consider that typically online, social communities tend to be self-policing and self-correcting.
So I would like to suggest that for a company to successfully embrace Enterprise 2.0, it should first decide how it wants to handle the content that will be generated through the use of such technologies. Would it not be reasonable to assume that all such information should be treated as the company’s digital assets?
So when it comes to providing governance around your Enterprise 2.0 solution, it might be useful to look at the following areas:
* Findability - how can you make it easy to find relevant content so users do not have to remember URLs or content locations? What can you do to provide true enterprise search capabilities? Can the search experience be customized?
* Retention - how long should content be retained both from a legal perspective and because of the business necessity to find older content? How about a mechanism to archive content that isn’t being actively used?
* Versioning - how many versions of content would you like to support? Make it easy to go back to a previous version but manage this effectively to minimize storage costs. Can you enforce storage quotas?
* Information Architecture - what guidelines do you want to provide around navigation and search? What kind of metadata do you want captured with different kinds of content to make it easy to find pertinent information? Do you have specific thoughts around taxonomy? Also, would you want to use workflows to manage document state? How about content approval policies? How do you integrate the content in the collaboration system with your enterprise portals?
* Customization - is the system customizable and does it provide the ability to turn functionality on/off as needed? What kinds of user customization of the system would be acceptable? How do you plan to verify that those customizations are safe to be deployed to your Production environment? Will there be a rollback mechanism?
* Security - provide adequate security so that content that needs special security can be effectively protected. Also verify that there are adequate mechanisms to audit and report system usage, and enforce information management policies such as retention, auditing, expiration, etc.
* The terms of use - define what terms govern the use of your system.
* Acceptable content - state upfront what kinds of content are acceptable i.e. regarding text, images, videos, audio, etc. Also specify your policy around sharing this content externally.
* Integration of such systems into the organization’s Enterprise Content Management system - How do you envision the information flowing from the location that provides free collaboration to your enterprise content management system? How do you plan to handle e-discovery? Where should the final, legal record of content reside?
* Tools - finally, evaluate the available Enterprise 2.0 tools to see which one best meets your needs in light of the requirements outlined above.
* Documentation - document your policies and procedures and the custom framework you are going to implement with respect to the software tool(s) selected above and publicize its availability.
To exercise the system, a pilot rollout could be considered and the guidelines and policies then be tweaked appropriately based on relevant feedback. But after that, IT should get out of the way and strive to effectively enable and empower the business to use these Enterprise 2.0 technologies.
One other thing I think companies should focus on is identifying and establishing the process for maintaining a single version of the truth when it comes to content management. Having multiple redundant versions of the same content for example in email, the user’s pc, a shared network folder, a collaboration space and a content management system is not a good idea not only in terms of governance and compliance but also very expensive when you think of backup and storage costs and not to mention the amount of time lost in finding out which is the latest version or the single version of truth. I had a colleague use the term “single point of truth” or SPOT and thinking in terms of SPOT should be a key focus area for governance. In this regard, you could for instance institute a policy that states that internally, email should not be used to forward documents but instead that a link to the document on the intranet or collaboration area be emailed. The same policy could be adopted for external communication as long as an extranet site is available to share content with external collaborators.
Today it is becoming common that the business is beginning to make use of Web 2.0 tools without overt IT involvement. With regard to Web 2.0, this is not as significant an issue since it is mainly about the consumer aspects and geared towards the individual user. However, when it comes to Enterprise 2.0, I do not think that is necessarily the best thing to do long term. For Enterprise 2.0, my recommendation would be that the business work hand-in-hand with IT and make use of a corporate vendor that builds and integrates its Enterprise 2.0 offering with existing infrastructure and has the vision, and proven financial and technical abilities to engineer a solution that can scale well and provide the necessary controls and mechanisms outlined above.
I would like to propose that IT be forward-looking and embrace Enterprise 2.0 technologies and strive to empower and enable the business to effectively use such technologies. And I would also propose that the business work in association with IT to achieve its ends instead of pursuing solutions that are good for a single department but may not scale well to the enterprise or are unable to provide the functionality needed long term.
How is Enterprise 2.0 different from Web 2.0?
June 3, 2008
The term “Enterprise 2.0″ was coined by Harvard Professor Andrew McAfee, during 2006, in an MIT Sloan Management Review article entitled “Enterprise 2.0: The Dawn of Emergent Collaboration”, as opposed to Web 2.0 (which was popularized by Tim O’Reilly in 2004).
When asked “What is Enterprise 2.0?”, the typical response might be “The application of Web 2.0 in the enterprise”. AIIM, the Enterprise Content Management association, states that there is more to Enterprise 2.0 than that. “Web 2.0 is focused on consumer and public-facing Web sites although that distinction was not explicitly made in the original definition.Enterprise 2.0 is much more about businesses’ adoption of “2.0 mindsets” than with the consumer facing side of the coin.” Plus, there is the lack of preciseness around the term Web 2.0.
AIIM defines Enterprise 2.0 as: “A system of Web-based technologies that provide rapid and agile collaboration, information sharing, emergence, and integration capabilities in the extended enterprise.” (see AIIM Market IQ, Q1 2008, “Enterprise 2.0: Agile, Emergent & Integrated”, by Carl Frappaolo and Dan Keldsen).
A couple of frameworks for Enterprise 2.0 include one from Prof. McAfee, which goes by the mnemonic SLATES (Search, Links, Authorship, Tags, Extensions and Signals), and another from Dion Hinchcliffe which goes by the mnemonic FLATNESSES (Freeform, Links, Authorship,Tagging, Network-oriented, Extensions, Search,Social, Emergence and Signals).
In similar fashion to AIIM, Forrester Research believes that “the term Web 2.0 has come to embody both consumer and business use of next-generation Web technology but that this lumping together of services is too imprecise to be practical” (see Global Enterprise Web 2.0 Market Forecast: 2007 To 2013 by G. Oliver Young dated April 21, 2008). Young states that as a result, “most pundits and technology strategists segment the market between consumer Web 2.0 services and business Web 2.0 services.” Forrester thus refers to “the business Web 2.0 market as enterprise Web 2.0, which encompasses Web 2.0 technology and service investments for both externally facing marketing functions and internally facing productivity and collaboration functions.” So for example, Forrester doesn’t include Blogger, Facebook or Twitter as Enterprise 2.0 services even though they are Web 2.0 services.
Forrester believes that “enterprise Web 2.0 technologies represent a fundamentally new way to connect with customers and prospects and to harness the collaborative power of employees.” They specifically refer to Enterprise 2.0 technologies such as blogs, wikis, RSS, podcasting, social networking, mashups, and widgets.
The list of Enterprise 2.0 technologies provided by AIIM is quite similar and consists of mashups, blogs, wikis, RSS, podcasting, social voting/ranking and social bookmarking.
One has to remember though that even if Enterprise 2.0 technologies such as the ones listed above provide for rapid and agile collaboration and empowerment, there has to be a cultural openness to this within an enterprise for it to truly be successful. So it’s not only about aligning the technology with the business, but aligning the culture with the technology that now becomes the challenge.
In future posts, we will take a look at some of these Enterprise 2.0 technologies and the cultural issues around the adoption of Enterprise 2.0.
Taxonomy: How can I get one of them?
June 3, 2008
“I’ll have one Taxonomy, a Diet Coke and some fries please!” Today things are fast-paced, sometimes too fast. Ready, Fire, Aim! is all too common. However, when building a taxonomy, it needs to simmer for a bit and let all the flavors come together. We are building something of substance here. So, where do we begin? Here is a little prep work to consider before you begin.
As in anything of substance, look towards your ancestors! Before beginning new journeys, look at the travels and teachings of the ancients. Once upon a time, in a land far far away, things were very expensive and the littlest of changes translated into huge dollars. The ancients lived in those lands and had to navigate through the treacherous waters of high hardware costs, outrageous communication costs, high people costs, massive lines of expensive code and hidden dependencies. In this land, things were new and every notion of business had to be created. In this time, the people who inhabited that land had to use their brains, all the time. There was no drop and drag. There were no visual approaches and pre-established templates. Things had to be thought through in great detail and time was spent on foundational issues…because if we don’t do it right from the beginning, it will be bad, very bad.
So, pull out that old book in your company and turn to that portion that equates to Leviticus – read about your Moses, who came down from the mountain with the law…what was good, what was not. Listen to those stories of old and take stock. It is said that history repeats itself. Why not leverage what’s been done and what’s been done with a rigor that I would say is not the norm of today.
Turn around right now and look at the shelf behind you. There, in the corner, you see it? There’s a book (or two) right there – yes, it’s the 3” black binder that has dust all over it. Take it down, offer a quick thanksgiving and open it slowly. Spend some time with the ancients and understand where you came from – you may just stumble upon truths so great that they make your hair white. At the very least you will walk where the great ones walked and who knows maybe you can point the way to the Promised Land!
You never know where you will find gold – roll up your sleeves and start digging around!
~ Scott Felten
Taxonomy: When you take the ‘text’ out of ‘Context’, you are left with a ‘Con’!
June 3, 2008
I have a friend who is a true genius. He has a PhD from Harvard University in Organic/Inorganic Chemistry. He also taught there for awhile. He met and married a very intelligent scientist from Mexico and they had three children. They thought that they were going to have developmental problems with their oldest - or at least that is what the doctors told them. You see, their oldest son did not speak right away. As a matter of fact, when their son was 1, then 2 then 3 years old and not speaking - they would take him to the doctors and the prognosis was the same, he was developmentally behind.
Then while he was 3 years old he spoke his first words. His mother told me this way. So, it was lunch time and ‘my son’ turned to me and said…now remember, this was his first words… “Mommy, may I have some lunch please”? She was shocked and of course very relieved. At the next doctor’s visit, she told the specialist the story. After looking at all the facts, the doctor described things as… Well, you son is very bright and a perfectionist. He was living in a multi-cultural home where both English and Spanish was spoken. Before he chose to communicate (with words), he had to fully understand the framework of grammar and its nuances. Then, he had to work through the process of selecting his base language (will it be English or Spanish).
Fast forwarding the story a few years finds ‘their son’ in first grade. Upon completion of further testing, they found that he was in the top 99.999 percentile in math - among college aged men and women.
This story is not much different than some of the issues we face each day with our clients. More times than not, each team, group, department speaks a different language. I’ll never forget the time where I was asked to develop a strategy for a recognized revenue solution - where they wanted to better align revenue, cost and time to properly manage cash flow and reporting. I was working directly for the CFO and one of the requirements was a report that grouped data as follows, she called it ‘The Region Report’:
- New Business
- East Division
- West Division
- Canada
- P&G
The solution was an education on taxonomy. As mature as this company was, they did not operate with a known taxonomy. Much like my friend’s son choosing not to speak until he fully understood what the framework was and how a taxonomy carried made the context known to both sides, I worked to help define the common taxonomy. Once we did this, we were rocking. This application became on of the strongest points in the organization, because we built a foundational canonical model around a true taxonomy that we socialized. This really became the hub of all data points and drove both master data efforts as well as metadata disciplines.
Looking back, it seems obvious and if you did your job well, this should be the case. Can you guess as to the structure in my oversimplified snippet of a real issue?
The above was decomposed to:
- Country (is a parent of region)
- Region (belongs to Country and is a parent of SVP)
- Senior Vice President (works within a Region and is the parent of a VP)
- Vice President (works for a SVP and owns one or more clients)
- Client (is owned by one or more (many to many) VPs and has a status of Type)
- Type (describes the client and consists of either ‘New’ or ‘Established’)
Also, we have the notion of a date for transactions as well as a time-based dimension for SVP, VP, Client and Type - so people, clients and type can reflect ownership movements.
It might seem painful to go through the rigor and discipline of establishing and socializing a true taxonomy, but its worth it. It’s not much different than building a house on solid rock…why rush and build things on sand. Don’t fall for a ‘Con’ - make sure your text resides within the proper context!
Happy Building,
~ Scott
Polls
Loading ...Latest Headlines
Recent Comments
- Christie Bautch on A Secret from an Old Man
- Jodie on A Secret from an Old Man
- Jodie on When You Have Trust
- Guy on A Secret from an Old Man
- Steven McWhorter on A Secret from an Old Man