Greetings,
At the risk of being one of those bloggers who "apologize" to their blog for inactivity, I will say that things have been busy here. Eye Street has partnered with Alfresco to develop the Web Content Management (WCM) training material, and has recently launched the Alfresco.com website. Needless to say I have been one busy person working on both of those activities. My colleague and I will be delivering this first course next week in Boston. The course is very well done (IMHO), and focuses not only on the technical skills, but real-world examples and concepts. There is also a thorough review of the new Alfresco.com architecture and CM strategy.
That said, Alfresco has GA'd their first version of a WCM add-on for the Alfresco 2.0 community release. This marks a very important milestone for them as an organization, as well as for the content management community as a whole. Time will tell what the impact will be on the major players in this space.
I will be ramping up my activity around here, so if there is a topic that you would like to cover, please feel free to email it to me. I've left off with some overview points with regard to the org structure and governance of ECM. In subsequent articles, I will begin to discuss the new architecture of Alfresco.com, and the strategy employed.
-Brent Kastner
Friday, February 23, 2007
Wednesday, January 17, 2007
And ODE to Shared Services
Continuing from last week's article, we will explore some of the management models that can govern a content management practice. There are really two main flavors of management approach with many shades of gray in-between.
The first, and the one I advocate the most, is the "shared service" model. While this management structure applies to many more disciplines than content management, it can be an excellent approach for large organizations with similar needs amongst the functional groups. This model is not without its' pitfalls as well. Shared services are often pitched to business by IT executives as a cost control and cost dilution mechanism. Many IT organizations present this model as a Utopian society in which the needs of the business are met consistently and economically by IT through the shared service model. While the roots of these ideals are generally admirable, in practicality many IT organizations fail to pull the model off as proposed. All to often the business is left with a service that meets some but not all of its needs. I've even bore witness to an IT shared service organization that blocked business sponsored initiatives because they did not fit into the shared service model. This is an extreme case, but a valid one to consider nonetheless.
So the million-dollar question is: how much shared service is practical for my business? I say million dollar because for some organizations this is a problem that can cost millions or more annually if not solved correctly. If your organization has more than one constituent group for content management or for any technical need really, then a shared service model should have entered someone's head at sometime. Any time you begin considering sharing resources (personnel, software, hardware), you should be considering HOW to share those resources. This is the beginning of a shared service model. How far it goes from here depends on many different factors, primarily; how many people need to be served, what budget must I adhere to, and what are the needs of the business constituents.
A common example of this is a medium to large sized organization with several internal uses for content management. To illustrate this idea, our fictional organization has an internal newsletter production team, a corporate intranet team, and a corporate Internet presence. Let's also say that this corporation produces revenue streams from their Internet presence. Do we apply a shared-service to this model? At first glance, this would be a good fit for a shared-service as long as we can gather a few facts to reinforce the concept. Firstly, the two internal groups would probably benefit from the shared-service approach. Cost dilution in the solution occurs because more than one business team is using the same hardware and software licenses, and even use the same support team to handle issues and outages. However, I would proceed with caution with respect to the third group.
The third group represents a revenue stream into the organization. To answer the shared-service yes/no question for this group we must analyze their needs and usage patterns. Are they a fast moving group? Do they change or improve their technology often to meet consumer demand? Is the Internet technology similar (platforms) to the internal teams? Can this group afford the trade-off between a one-size fits most approach, at a lesser cost, and a cater to my every need at a greater cost? If the answer is yes to one or more of the questions above or no to the last two, you will probably need to consider placing that group outside of the shared-service model. Typically, shared-services aim for roughly an 80% coverage of any one business groups needs to keep costs down, and reusability up. Sometimes this is ok, but be aware that a shared-service model is not something that should be force fed to the business (see extreme example above), but should be applied with thought and where appropriate.
Back to our Internet team example. On a few occasions, I've advocated the creation of a Business IT team to buttress the shared-service model in instances where there is not an exact fit. This group is structured as an overlay to the current shared-service model but provides extra attention to the teams that need, and can make a case for paying for it. In this way you have the cost savings inherent in the base shared-service, with the personal attention that revenue generating business groups deserve.
The second type of governance model is tied to the departmental implementation discussion. In this day and age it is pretty hard to advocate the cost of content management software, hardware, and personnel to be dedicated to the needs of one group or department. For some organizations, who do not intend to extend content management capabilities beyond one group, this may be the only option.
Thanks for reading, I'll post again soon!
Brent Kastner
The first, and the one I advocate the most, is the "shared service" model. While this management structure applies to many more disciplines than content management, it can be an excellent approach for large organizations with similar needs amongst the functional groups. This model is not without its' pitfalls as well. Shared services are often pitched to business by IT executives as a cost control and cost dilution mechanism. Many IT organizations present this model as a Utopian society in which the needs of the business are met consistently and economically by IT through the shared service model. While the roots of these ideals are generally admirable, in practicality many IT organizations fail to pull the model off as proposed. All to often the business is left with a service that meets some but not all of its needs. I've even bore witness to an IT shared service organization that blocked business sponsored initiatives because they did not fit into the shared service model. This is an extreme case, but a valid one to consider nonetheless.
So the million-dollar question is: how much shared service is practical for my business? I say million dollar because for some organizations this is a problem that can cost millions or more annually if not solved correctly. If your organization has more than one constituent group for content management or for any technical need really, then a shared service model should have entered someone's head at sometime. Any time you begin considering sharing resources (personnel, software, hardware), you should be considering HOW to share those resources. This is the beginning of a shared service model. How far it goes from here depends on many different factors, primarily; how many people need to be served, what budget must I adhere to, and what are the needs of the business constituents.
A common example of this is a medium to large sized organization with several internal uses for content management. To illustrate this idea, our fictional organization has an internal newsletter production team, a corporate intranet team, and a corporate Internet presence. Let's also say that this corporation produces revenue streams from their Internet presence. Do we apply a shared-service to this model? At first glance, this would be a good fit for a shared-service as long as we can gather a few facts to reinforce the concept. Firstly, the two internal groups would probably benefit from the shared-service approach. Cost dilution in the solution occurs because more than one business team is using the same hardware and software licenses, and even use the same support team to handle issues and outages. However, I would proceed with caution with respect to the third group.
The third group represents a revenue stream into the organization. To answer the shared-service yes/no question for this group we must analyze their needs and usage patterns. Are they a fast moving group? Do they change or improve their technology often to meet consumer demand? Is the Internet technology similar (platforms) to the internal teams? Can this group afford the trade-off between a one-size fits most approach, at a lesser cost, and a cater to my every need at a greater cost? If the answer is yes to one or more of the questions above or no to the last two, you will probably need to consider placing that group outside of the shared-service model. Typically, shared-services aim for roughly an 80% coverage of any one business groups needs to keep costs down, and reusability up. Sometimes this is ok, but be aware that a shared-service model is not something that should be force fed to the business (see extreme example above), but should be applied with thought and where appropriate.
Back to our Internet team example. On a few occasions, I've advocated the creation of a Business IT team to buttress the shared-service model in instances where there is not an exact fit. This group is structured as an overlay to the current shared-service model but provides extra attention to the teams that need, and can make a case for paying for it. In this way you have the cost savings inherent in the base shared-service, with the personal attention that revenue generating business groups deserve.
The second type of governance model is tied to the departmental implementation discussion. In this day and age it is pretty hard to advocate the cost of content management software, hardware, and personnel to be dedicated to the needs of one group or department. For some organizations, who do not intend to extend content management capabilities beyond one group, this may be the only option.
Thanks for reading, I'll post again soon!
Brent Kastner
Thursday, January 11, 2007
Enterprise Content Management or Really Big Departmental Solution?
Enterprise Content Management or (ECM) is a bit of a buzzword for many organizations that I've dealt with. The vast majority of large to very-large organizations are using "ECM" as more of an exploded departmental implementation rather than as a true enterprise level tool-set. This is to say that the focus for content management is for the benefit of small groups of individuals, relative to the whole of the organization, rather than global use. This is OK for the most part as many organizations do not look at the hidden cost of a true ECM system. In this series of articles, I will explore the difference between departmental and ECM solutions, I will discuss the cost of ECM (in several different terms), and will hope to lead the reader to some conclusions as to the proper direction for their own organizations.
First, let's highlight the difference between enterpise content, and departmental content. Typically whilst consulting I will hear comments and phrases such as, "The internet marketing team needs to change content on our website faster to keep our site current and relevant." for example. This statement, while a powerful one, is directed at a specific set of users for a specific set of goals. It is very clear what is intended for content management. That said, this would be an example where a departmental implementation of content management would suffice. It is then the role of IT, or the independent consulting firm, to identify where the bounds of this request lie. It is possible that other groups within this same fictional organization are experiencing like issues with contracts, documents, and/or photographic studio's to name a few. Without additional groups to target, we're looking at a departmental solution.
Why is this important? Who cares if it is departmental or enterprise?
To put it bluntly, this determination is very important in the early stages of needs identification. Both business owner and IT representatives should have a firm grasp on the near and long-term goals of content management. The first and main consideration is the content management tool-set required to perform the task. If the organization in question has only one main group of constituents intending to facilitate one or more related activities, then there is no need to employ enterprise-level content management software. In a sense this is like buying the super-stretch Hummer® limousine when the party-bus will do. The previous being said, I've more often than not been prepared to offer up a nice concise departmental solution when a business or technology owner will drop a statement such as this: "We're having trouble synchronizing our web and print mediums", or "The process of getting a new product to market is very painful because of the many groups involved". These statements are often indications that there is a deeper need for content management and potentially business process management as well. I would then expect to reconsider the tool options to support multi-platform, open-integrations, and related "technology freedoms" that become available with higher end content management tool-sets.
So now we have a sense of whether our implementation is departmental or enterprise level. With this information we can begin to assess what the management structure for content management will look like. This is the main topic of my next article.
-Brent Kastner
First, let's highlight the difference between enterpise content, and departmental content. Typically whilst consulting I will hear comments and phrases such as, "The internet marketing team needs to change content on our website faster to keep our site current and relevant." for example. This statement, while a powerful one, is directed at a specific set of users for a specific set of goals. It is very clear what is intended for content management. That said, this would be an example where a departmental implementation of content management would suffice. It is then the role of IT, or the independent consulting firm, to identify where the bounds of this request lie. It is possible that other groups within this same fictional organization are experiencing like issues with contracts, documents, and/or photographic studio's to name a few. Without additional groups to target, we're looking at a departmental solution.
Why is this important? Who cares if it is departmental or enterprise?
To put it bluntly, this determination is very important in the early stages of needs identification. Both business owner and IT representatives should have a firm grasp on the near and long-term goals of content management. The first and main consideration is the content management tool-set required to perform the task. If the organization in question has only one main group of constituents intending to facilitate one or more related activities, then there is no need to employ enterprise-level content management software. In a sense this is like buying the super-stretch Hummer® limousine when the party-bus will do. The previous being said, I've more often than not been prepared to offer up a nice concise departmental solution when a business or technology owner will drop a statement such as this: "We're having trouble synchronizing our web and print mediums", or "The process of getting a new product to market is very painful because of the many groups involved". These statements are often indications that there is a deeper need for content management and potentially business process management as well. I would then expect to reconsider the tool options to support multi-platform, open-integrations, and related "technology freedoms" that become available with higher end content management tool-sets.
So now we have a sense of whether our implementation is departmental or enterprise level. With this information we can begin to assess what the management structure for content management will look like. This is the main topic of my next article.
-Brent Kastner
Subscribe to:
Posts (Atom)